Store OTAA session details to survive deep sleep on Blue Pill (STM32F103)?

End Devices (Nodes)
#1

Greetings,

After spending what may have been too much time on it, I think I am ready to conclude that it is not possible to store OTAA session information on the STM32 Blue Pill during deep sleep. There just are not enough BKP registers to store the necessary keys on this chip.

Have I missed something? Has someone found a clever trick to get it to work?

#2

You only need to store the counters. The keys you can store in program memory (emulated EEPROM). Because the keys are infrequently changed, you will not need to be concerned with flash memory endurance issues.

2 Likes
#3

Ah! I am quite new to STM32 and so this is news to me. Thank you, this is very helpful.

Do you know of a good implementation of OTAA in deep sleep on the Blue Pill that I can look at? I have not been able to find one.

#4

While it sounds like you don’t actually need it, don’t forget that you can glue an I2C EEPROM to the bluepill board and connect a few wires.

If you design a custom board, it’s very much worth putting a footprint for an external EEPROM or NOR flash - you can always leave it unpopulated in production. Dealing right now with a board that was designed without by others, and would be so much more capable with additional local storage outside the MCU.

Also when going custom consider other MCUs - the STM32L0’s have yet lower power, and actual EEPROM inside. It’s too bad there’s no bluepill version of the STM32L073.

And then there’s the Murata CMWX1ZZABZ-078 which gets you both an SX1726 and an STM32L082 in the same SMD sub-module.

1 Like
#5

And you’ll need to store some more, see: OTAA best practice: how to not join every time?

#6

Good points, thank you.

It would seem like the most urgent of these would the keys, device address, and counters, which I had been planning on (and now have working thanks to Sandgroper), and the ADR parameters, which I had not thought about.

I am using LMIC, and after poking at this for a few days I am not completely clear on the data points I should be capturing (adrTxPow vs. txpow? datarate? Are there others? Should I be tracking adrAckReq, and how does that work?) and at what stage in the cycle I should be capturing them. Advice would be most welcome. Many thanks.

#7

For anyone designing boards, it would be a very good idea to check that a device footprint is compatible with the the 8pin SOIC FRAMs.

An EEPROM may have a write endurance of 1,000,000 times which sounds a lot, but FRAMs have a write endurance of 100,000,000,000,000 so when written to 1000 times a second they would last 3,170 years …