[BUG] Base build EFM32ZG falls to the default handler

[Brando753]

When using the default source file provided, only modified to use a different port/pin for the LED on this chipset and to have the printf + stdio removed, results in the device catching in the default handler (efm32-base/device/EFM32ZG/Source/GCC/startup_efm32zg.S:267) and hanging. This was tested on a custom board running a EFM32ZG108F8 MCU. Monitor reset halt does not work just traps in the handler, running a jump using the reset handler results in the same behavior. Please find attached the output if make VERBOSE=1 as well as the very basic modifications I made to this source file just in case I introduced the problem.
make.txt

main.c.txt

[Brando753]

This issue still persists for me and its blocking development on my project. Going to try and build the same code I have for all of my starter kits and report what works and what does not. @ryankurte any idea what could cause this? It appears to be building for the correct processor and the code is dead simple, I am not sure what could be happening.

[ryankurte]

Uhoh :-/

I have no idea sorry, we use a variant of this with the ZG but there must be some difference between the build args.

Will see if I can get hold of a working version / might be able to email it to you to play with.

[Brando753]

Alright so I pulled out all of my EFM32 starter kits to test this code on.

The EFM32 Gecko Starter kit (EFM32-G8xx-STK) with the EFM32G890F128-BGA112 MCU works with this code
make.txt
flash.txt

The EFM32 Happy Gecko Starter kit (SKSTK3400A) with the EFM32HG322F64 MCU Works with this code
cmake.txt
make.txt
flash.txt

The EFM32 Leopard Gecko Starter Kit (EFM32LG-STK3600) with the EFM32LG990 works with this code

cmake.txt
make.txt
flash.txt

The EFM32 Zero Gecko Starter Kit (EFM32ZG-STK3200) with the EFM32ZG222F32 works with this code.... so perhaps this is a specific chip issue? My custom board works fine in Simplicity Studio....
cmake.txt
make.txt
flash.txt

The EFM32ZG Custom board running a EFM32ZG108F8 works in Simplicity Studio but not with efm32-base. Flashed using a Jlink-Edu.
cmake.txt
make.txt
flash.txt

[Brando753]

@ryankurte I dont see anything in these cmake, make, or flash files that suggests what could be going on. Is there any other files worth checking out? Are the linker files and startup scripts in this project the same ones that ship with Simplicity Studio? Is there anything I can do at this point?

[ryankurte]

Hmm, I differ all the files from the ZG you attached and they see to be the same except for the device name :-/
We use a bunch of G/LG/PG/WG/GG/FG devices with this and it's ok, but I have always had unknown struggles with cortex-m0 devices.

The files are (currently) the 2017 Gecko SDK suite v1.1 (emlib v5.2.2), which is one of the options when installing SDKs in simplicity studio. So, it should be. I also diffed against the 2016 exx32 SDK (emlib 4.4.1) and there were no notable changes. The linker file is basically just copied from the Device/XXXX/Source/GCC dir into the build dir, so you could check that against the silabs IDE one. Only thing it's not doing is overriding the flash size, so you can definitely compile applications that are too big for your device.

Could you upload the .dmp and .map files that should be output into your build directory?
The map should show where everything is being located in memory which may be a good check, and the .dmp is a full disassembly of your application (if you're willing to share it) that might help work out what's up.

Grasping at straws, but, do you have a reset button or something on board you can try load then physically reset (see: errata? Alternately, make reset will trigger a device reset that is for some reason more reliable than the gdb internal reset.

[Brando753]

The source I am running is the exact same as the one posted at the top of this bug request, a very trivial blinking LED code, as such all of the code is shareable of course. The code reports a size of over 4K but I have 8K program space so I doubt it is overfilling it. I have attached all output from the build directory.
build.zip

This board unfortunately does not have a physical reset button doing a make erase; make flash; make reset; does not seem to work either :(

[Brando753]

So I got some spare time to re-look into this project and after a little tinkering around figured out the issue, now I just feel like an idiot. So it turns out there is a very good reason the code worked on all the starter kits but not on my EFM32ZG108F8 MCU, and that is because Silicon Labs ships the standard linker scripts (which where imported with this project) for their starter kits but generates custom linker scripts when you create a project for a specific chipset. I replaced the linker script in the efm32-base with the one simplicity studio generated and everything worked. The only differences I can tell where the sizes defined for storage and ram (8K instead of 32K). As such I don't think this is a bug with this project, though it should probably be documented that you need to modify the sizes on the linker scripts as they are not included by default. Sorry for wasting your time with this bug report.

[ryankurte]

Awh no, sorry you had the issue and good work tracking that down! I'd definitely call this a bug 😂
The flash sizes don't really matter (unless you run out, but you would get an error flashing then too), but the incorrect RAM size would mess everything up :-/

In an internal version of this we require a FLASH/RAM_START/SIZE to be defined when you select the CPU, but that seems like a bit of overhead for every user. Do you think a note in the readme and an option to override the auto-discovered linker script would work well enough?

[Brando753]

Another possibility I can take a look into would be writing a small script that reads the Simplicity Studio XML files and auto creates the linker scripts much like simplicity studio does. This would then have to be done every time the SDK is updated but it would then let you pick the specific chip linker file. Just a thought.

[blu006]

I'm just commenting here saying that I had the same linker script bug. I had to manually set the memory size in simplicity studio to get it to generate the correct linker script.