LoRa NVRAM clear on restore issues



  • I had a couple of LoPys on which I had to change batteries today (batteries fully exhausted).

    The initial idea was to replace the battery and have the LoPys start again as if they had woken up from sleep. However that did not work, and I ended up having to re-join.

    My guess (don't have detailed logs for that though) is that there could be an issue with the recent logic on lora.nvram_restore which clears the NVRAM after the restore. This probably leads to situations that go like this:

    • battery is close to exhausted
    • LoPy still able to wake up
    • starts, nvram_restores, attempts to send
    • fully exhausts battery and stops before (or during) nvram_restore

    The result is that when a new battery is inserted, it won't be able to nvram_restore.

    I'm not sure what the consequences would be if we just kept the previous state and sent a new frame with the same counter (would just the "duplicate" packet be ignored, or would that trigger other issues?).

    The alternative (which I'm going to implement for now) will be to re-join automatically if needed (join was done manually when setting up the device only until now), but that seems a bit overkill.

    For reference, this is running 1.16.0.b1.

    Thoughts?



  • @jcaron Thanks.
    Just to note this method works also for both a software reset AND powercycle.



  • @han I usually do the initial join process manually moving to the load/work/send/save/sleep cycle.

    But if you do a nvram_restore and there's nothing to restore, has_joined will return false and you can do your join as usual.

    You logic should be something along the lines of:

    • create lora object
    • nvram_restore
    • if has_joined is false, join, and wait for has_joined to become true
    • do the work, send the data
    • nvram_save
    • deep sleep


  • @jcaron how did you program the nvram_restore()? and where did you placed the rule in your code?

    I have some trouble with the first time when the Lopy is starting up and connecting.
    If the module is starting up with nvram_restore active, is not joining. But when I make the nvram_restore function inactive it joins directly when the module is starting up.

    Kind regards,



Pycom on Twitter