mstempin wrote:The SDK-4.0.1 is 2 year old...
As the EFM32 MCU does not contain an EEPROM, the Sigfox sequence number is stored as a bitmap burned bit by bit in a Flash sector in order to optimize the Flash memory wear leveling. As compared to previous SDK versions, the SDK-4.0.0 had to move around this bitmap sector in Flash memory, requiring a hot copy upon first boot up. There was a bug in this function, causing the sequence number to be lost in some random cases.
But this never happened since then, as this Flash sector is protected from erasure both using the built-in bootloader and using the JTAG/SWD Flash utilities, as this area is not part of the firmware.
However, Flashing a wrong firmware may destroy this are, and potentially the Sigfox ID and key stored in the module, turning it into a non-operating module.
I have a working application (SDK 4.0.1) for TD1204 which I recompiled in the newest SDK. Apparently the binary size increased which lead to an error during flashing. The message is "invalid flash address", during 'erase flash' step at 26% of the flashing process..
After flashing a working binary, one that does actually fit, the device messages are not received anymore by the sigfox network.
Can it be that the module lost its Sigfox ID and key like mentioned above?
How can I recover such a device?
Or even more important, how can I expect a flashing problems when looking into the build result like the following?
arm-none-eabi-size --format=sysv -x App03.elf
App03.elf :
section size addr
.text 0x1b428 0x0
.eh_frame 0x4 0x1b428
.rodata 0x277c 0x1b42c
.data 0x750 0x20000040
.bss 0x1e80 0x20000790
.stack 0x800 0x20002620
.debug_aranges 0x24c0 0x0
.debug_info 0x279ba 0x0
.debug_abbrev 0x7007 0x0
.debug_line 0x23474 0x0
.debug_frame 0x7bac 0x0
.debug_str 0x8220a 0x0
.debug_loc 0x4f8c 0x0
.debug_ranges 0x2170 0x0
.ARM.attributes 0x27 0x0
.debug_macro 0x2203f 0x0
.comment 0x60 0x0
Total 0x127be5