Questions and discussions about the software that runs on the TD RF module itself.
disk91
 
Posts: 58
Joined: Thu May 07, 2015 4:30 pm

Condition where sigfox sequence number is reseted

by disk91 Mon Feb 15, 2016 3:07 pm

I experienced sigfox frame number reset to zero after having reflashed the TD1204. It is something new with my last version of firmware and usually the sequence was not broken by a new firmware. What are the conditions where we can have a such reset ? (this cause the device to not be able to communicate on sigfox network until the sequence is disengage in backend)
disk91
 
Posts: 58
Joined: Thu May 07, 2015 4:30 pm

Re: Condition where sigfox sequence number is reseted

by disk91 Fri Feb 19, 2016 4:46 pm

no idea about this question ?
giovanni
 
Posts: 10
Joined: Mon Jun 22, 2015 1:04 pm

Re: Condition where sigfox sequence number is reseted

by giovanni Mon Feb 22, 2016 8:07 am

I would like to confirm the same condition and I haven't been able to track down the cause of this issue. Never had issues with this until recently.
giovanni
 
Posts: 10
Joined: Mon Jun 22, 2015 1:04 pm

Re: Condition where sigfox sequence number is reseted

by giovanni Mon Feb 22, 2016 8:24 am

Just found this in the changelog of the libtdcore:

# Version 4.0.1 #
## Bug Fixes ##
### SIGFOX: ###
* Corrected a problem causing loss of SIGFOX sequence number after an upgrade from previous SDKs

So it isn't the fist time this issue has popped up.
User avatar
mstempin
 
Posts: 168
Joined: Thu May 07, 2015 9:24 am

Re: Condition where sigfox sequence number is reseted

by mstempin Tue Feb 23, 2016 2:34 pm

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.
edhowork
 
Posts: 10
Joined: Mon Jan 04, 2016 6:33 am

Re: Condition where sigfox sequence number is reseted

by edhowork Fri Feb 26, 2016 6:31 am

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
disk91
 
Posts: 58
Joined: Thu May 07, 2015 4:30 pm

Re: Condition where sigfox sequence number is reseted

by disk91 Sat Feb 27, 2016 12:20 pm

Hello Michel,
I'm using last sdk version and I do not see why my firmware would be wrong compared to the previous version. The only reason I see is my firmware is about 128Kb.
I can send you the firmware for a try. I have no other problem than this sequence number reset with this FW.

Sincerely,
Paul
User avatar
mstempin
 
Posts: 168
Joined: Thu May 07, 2015 9:24 am

Re: Condition where sigfox sequence number is reseted

by mstempin Mon Mar 21, 2016 9:20 am

Hi Paul,

Please look at the linker script file for details. Basically, we used the 512-byte block at the top of the Flash memory map to store all persistent variables, including the ATSxxx registers. Then the Sigfox sequence number was introduced, and we used another 512-byte block just below it to store it as described in my previous post.

But we faced situations in this SDK where the persistence area was getting too small, and we had to swap the 2 areas in order to have a variable (and bigger persistence area growing down. This was taken care of transparently by the libraries, so the first time a firmware with the new Flash map is launched, it automatically perform a copy of the sequence number bitmap to its new location.

The problem may be that you overwrite the bitmap with a firmware that is too large. This should not happen, since these areas are accounted on the link script, but there may be a bug here when you reach the limit.

Usually, you get big firmwares when you compile in Debug mode. Even if it is very convenient for step-by-step debugging, I suggest compiling in Release mode, as GCC is not very efficient on Cortex ARM CPUs when you turn off all optimization flags.
Return to Firmware

Who is online

Users browsing this forum: No registered users and 25 guests