NVM, clear CTX after every send

[dagerlandsson]

Yet another NVM question.
In our application it is not possible to keep the CTX after each send "session". It is possible to store the the complete NVM.

Our idea is to run the stack in this way:

1. Initialize the stack
2. restore the NVM context
3. do the send
4. when the LoRaMacIsBusy() function returns false power off the module. NVM is stored to persistent storage before module is powered off.

Will this work? Or is there any cases where the information in CTX, or any other variables, is needed between transmissions?

[dagerlandsson]

I have now tested to only use NVM between every LoRa transmission. e.g. clear CTX and restore from NVM.

My conclusion is that it does NOT work.
There is a lot of information and bugs that prevents this from working. Some examples:
Commands is not stored, so many MAC commands fails (xxxxxAns reply is not sent to server)
DutyCycleReq is not working due to LastTxOnAir is always zero (lost as it is CTX)
When compliance test turns dutycycle on/off NVM is lost due to wrong CRC (when enable/disable dutycycle variable is changed in NVM but not triggered a CRC update. NVM with wrong CRC will be stored and then not restored)

[janakj]

I came to the same conclusion while looking at the possibility of shutting down the modem (with RAM not preserved) between transmissions. There appears to be plenty of state that is only kept in RAM that will not be restored from NVM. In some cases, this also results in issues if you reboot the modem at the wrong time, e.g., #1292.

I think the current NVM API is quite nice and definitely a step in the right direction. To make it more robust, it would be useful to extract all variables with a static lifetime, i.e., global state, into a separate data structure so that the application could choose what to save in NVM, in addition to the existing NVM-backed variables.

I am also of the opinion that the LoRaWAN specification could do a better job of explaining the required lifetime of the various node-level parameters. Some state needs to be only kept across the current transmission, other parameters need to be preserved for the duration of the network session (activation), etc. LoRaWAN, especially in the 1.1.x version, is a surprisingly stateful protocol.