Issue with Sigfox Uplink Sequence Number Reset in Multi-Stack Application (LoRaWAN, Sigfox, WMBUS)

[Taksh]

Hello developers,

I am currently developing all-in-one AT slave firmware for STM32WLE5CCUX, which can handle both LoRaWAN and Sigfox AT commands. I have successfully implemented and tested AT slave drivers for LoRaWAN and Sigfox using the video linked below:

https://www.youtube.com/watch?v=HsrL-7WmhUE 

In my application, I publish hourly data on the LoRaWAN server and Sigfox backend, one at a time. What I am doing is first transmitting the data to the Sigfox backend, then switching to the LoRaWAN stack to send the data to the LoRaWAN server. So far, everything has been working well.

Now, I want to implement one more stack, which is WMBUS, into my application.

For this purpose, I got the drivers for the MBUS stack from STACKFORCE and successfully implemented them into my application.

Now in my application, three different stacks are running. I am publishing hourly data on the LoRaWAN server, Sigfox backend, and MBUS collector, one at a time.

Everything has been working fine except for the problem with the Sigfox uplink (sequence number). The uplink from Sigfox arrives every time we transmit data from the node to the Sigfox backend. However, the sequence number resets to ZERO after reaching 21. It is expected to proceed to 22 but resets to 0 instead.

The message at the Sigfox backend server is:

Invalid message sequence from Device #3000ACC: expected 22, actual 0.

Below is a screenshot of the Sigfox backend server.

I don't know why this happens. If I simply exclude the WMBUS from my code, everything works fine.

I have no idea why this is occurring. Can anybody suggest a solution?

Below are the screen shorts of the memory occupies with WMBUS stack and Without WMBUSTACK.

Memory_without_WMBUSMemory_with_WMBUS

Is this issue occurs due to the memory occupancy?

[Tesla DeLorean]

ROM and SIGFOX_DATA seem to overlap.

Shrink the ROM size allocation in the linker script to accommodate the SIGFOX_DATA, ie 256K - 768B

[Taksh]

Hello @Tesla DeLorean 

Thanks for the response.

Below is the memory size allocation used in linker script file by default used. In that the SIGFOX_DATA has been allocated in between the ROM.

Default :

/* Memories definition */

MEMORY

{

ROM (rx) : ORIGIN = 0x08000000, LENGTH = 256K

SIGFOX_DATA (rx) : ORIGIN = 0x0803E500, LENGTH = 768 /* memory dedicated to User embedded Keys */

RAM1 (xrw) : ORIGIN = 0x20000000, LENGTH = 32K /* Non-backup SRAM1 */

RAM2 (xrw) : ORIGIN = 0x20008000, LENGTH = 32K /* Backup SRAM2 */

}

I have modified the linker script memory region in which the SIGFOX_DATA has been placed

at the end of ROM.

Below is the modified memory region in linker script file.

MEMORY
{
ROM (rx) : ORIGIN = 0x08000000, LENGTH = 256K - 768
SIGFOX_DATA (rx) : ORIGIN = 0x08040000 - 768, LENGTH = 768 /* memory dedicated to User embedded Keys */
RAM1 (xrw) : ORIGIN = 0x20000000, LENGTH = 32K /* Non-backup SRAM1 */
RAM2 (xrw) : ORIGIN = 0x20008000, LENGTH = 32K /* Backup SRAM2 */
}

But the issue still remains the same in sigfox counter(sequence number) has been reseted.

[Tesla DeLorean]

The linker fix will get you an error if you have too much content to allow the SIGFOX data to reside cleanly

>>But the issue still remains the same in sigfox counter(sequence number) has been reseted.

Yes, you'll have to do some debugging, start by determining where the count lives, where it's incremented, and then instrument that, or add a watch point to see who's incrementing it twice or where the modulo is failing.