Don't erase lora context on nvram_restore()

[d.alvrzx]

Re: LoRa NVRAM clear on restore issues

Hey everyone:

I'm referencing this topic, because it's been a big problem for a large number of LoPy4 we are running in the field. Basically, we would greatly benefit from lora.nvram_restore() not erasing the current context until a lora.nvram_save() or lora.nvram_erase() command has been issued.

Some devices in the field are failing at doing the restore and, since are running ABP, then they go out of sync with the server because the fCnt resets (while the server has no way of knowing this). I know that going with ABP brings these kinds of issues, but OTAA just isn't an option for us because we are having trouble with the LoPy hearing the Join Accept packets from the server - and thus never join.

So, the kind of behaviour we would like, would be:

1. Turn on LoPy4
2. Attempt to restore
3. If the LoPy powers off during the restore (which can happen in our case, since the devices are manually connected/disconnected from their power supply), don't erase the lora context.
4. When the LoPy powers on again, attempt to restore again (which should work, since the context was not erased before). However, since no lora.nvram_save() has been called, don't erase the past lora context from memory even if the restore was successful.
5. Then do the work, transmit, lora.nvram_save() (which would update the lora context in memory).

I feel this would be a more foolproof method of handling these functions, but of course I may be missing something, and Pycom didn't implement this in this manner because of some othe reason?

Currently, if we fail once at doing the restore, the next time we attempt it, the fCnt is lost and we're out of sync with the server until the fCnt surpasses the value saved on the server. This would save us so many problems...

Any way this can be implemented? What do you guys think?

Best wishes,

Dan

p.s. Running the following firmware: (sysname='LoPy4', nodename='LoPy4', release='1.20.2.rc6', version='v1.11-01f49f7 on 2020-02-28', machine='LoPy4 with ESP32', lorawan='1.0.2', sigfox='1.0.1', pybytes='1.3.1')

[robert-hh]

@d-alvrzx I strongly support this request. I see, that restoring some of the data may cause trouble, if restore is executed multiple time w/o a save in between. Like the packet counters. But that is less cumbersome than loosing all data.

See also my notes here to retrieve individual elements: https://forum.pycom.io/topic/5922/an-alternative-to-nvram_save-restore-using-the-sd-card/6?