OTAA key retention after reset

[LaurentHB]

Hello,

Here's my situation. I am using a LoRaWAN end device that connects to a network using OTAA.

To reduce the power consumption as low as possible, I want to put my MCU in the lowest possible power state between transmissions. This state would mean a reset of the MCU, losing everything but 32 Bytes of memory that are not powered down.

I would like to store the NWKSKEY and APPSKEY acquired from the OTAA to these 32 bytes and reassign them after the reset so I can bypass the join procedure completely and start sending data using the same session right away.

Is there anything else I would need to store for that to be possible or are these 2 keys enough? Is that even possible with the API? ( My guess is that worst case, I can probably just switch to ABP and set all the values and the gateway would probably accept them )

Thanks!

Laurent

[FoujanetG]

Hi,

You need also to store the UplinkCounter, the DownlinkCounter, All parameters of the ADR(SF, TXpower, CFlist...).
I think you need to use the flash to store theses parameters, it depend on the MCU you use for your project. Some MCU have a RAM with retention even in very low power mode.

Guillaume

[nestorayuso]

You must save ChannelParams_t Channels[LORA_MAX_NB_CHANNELS], the complete LoRaMacParams_t struct and many more.

A modern Cortex MCU consumes about 1.5uA in sleep mode with full state and RAM retention and RTC 32KHz crystal running. And about 50nA in stop mode with small RAM region retention.

Are you sure you need to go as low as 40nA? what is the use case?

I have LoRaMac-node stack implemented in EFM32 and my board consumes less than 2uA in sleep mode

[LaurentHB]

The optimal power mode I'm hoping I can use does not allow RAM retention. Only these 32 bytes, if it's not enough I'll go up to a state that allows more but if possible I want to avoid it.

No RAM let's me have 1.5-2 uA and with RAM retention I'm jumping up to 3-5 uA. It would be doable for my use case but definitely not near optimal.

UplinkCounter, the DownlinkCounter, All parameters of the ADR(SF, TXpower, CFlist...).

I have ADR disabled (moving device) so I do not care about these parameters. I wouldn't mind resetting the Up/Downlink counters if I have to, currently not using this info. Is that problematic?

You must save ChannelParams_t Channels[LORA_MAX_NB_CHANNELS], the complete LoRaMacParams_t struct and many more.

The device will go back through it's initialization process I believe these would just be reset to what they were before the reset anyway. I don't believe I need to save them.

Thanks for the input!

[LaurentHB]

To add to my initial question. If I were to actually choose a mode that retains RAM, what would I need to do so my execution can resume correctly without going through JOIN. Do I need to skip the INIT state too? I'm slightly confused with what needs to be done.

My MCU will go through a reset so the execution doesn't simply resume after where it went to sleep.

Thanks!

[nestorayuso]

In the LoRaMac example, after sending, the main state machine goes to state DEVICE_STATE_SLEEP consumming about 2uA.
Prior to go to sleep you must program something to be able to wake-up, in the example it schedules a periodic timer event:
TimerSetValue( &TxNextPacketTimer, 5000 );
TimerStart( &TxNextPacketTimer );
Or you must activate some interrupt in some GPIO pin or peripherical and add the next code in the corresponding IRQ_Handler:
DeviceState = DEVICE_STATE_SEND;

[LaurentHB]

Yes, I have that done, but to save the most power the interrupt comes from an internal module that will "reset" the device in the process ( I'm not using any of the MCUs used for LoRaMac examples) . It can still retain RAM during this procedure. The execution will pick up at the beginning of the code though, not like in the LoRaMac example. I'm wondering what would need to be done so I can jump to DEVICE_STATE_SEND with the right settings.

Currently, when I reset from this interrupt, the first thing I do is set DeviceState = DEVICE_STATE_SEND, but that doesn't seem to do the trick, I'm not receiving packets on my gateway.

Thanks!

[jmunt]

If you have a sleep mode that has user RAM retention but device reset, you should check the state of registers after this specific reset condition. It's likely that the deep sleep mode has special register reset conditions that are neither the same as POR or the higher power Sleep/Stop modes which typically don't have register reset conditions. You should also run tests to check that user RAM is truly being retained like you expect. If all this is working and you skip stack re-initialisation then I think it shouldn't be a problem to transmit a new packet the same way you would out of any other sleep/stop/idle mode.

[mluis1]

This issue is covered by the #364 issue.

[ThomasUnivRennes1]

@LaurentHB
Hi,

did you manage to save the necessary keys and parameters?

[LaurentHB]

@ThomasUnivRennes1 It's been a while since I touched that project. If I recall correctly I ended up just using a low power state with RAM retention. Sorry I can't be of much help!