ArmDeveloperEcosystem/lorawan-library-for-pico

Shutting down the stack to be sure NVM is no longer being written to before power-down

shabaz123 opened this issue · 3 comments

Hello,

I had a quick (hopefully easy) query : )
What do you suggest could be the best way to shut down the stack, or at least to know when the NVM is not being written to? Is there a lorawan_close() type of function?
The reason I'd like to do such a shutdown or be able to be sure when NVM is not being written, is because I managed to corrupt the portion of Flash that the LoRaWAN stack uses as NVM somehow, I believe through removing power at an incorrect time. I'd like to first check (or shutdown the stack) that it is not writing to NVM, and then remove power. I have only corrupted it once, but I wanted to reduce the risk of it occurring.

For now, I can do a force erase of the NVM portion on startup if corruption has occurred, so it's a minor thing.

Also, I was wondering, when does the NVM get written to? Is it when lorawan_init_otaa() is executed, or also at any other point?

Many thanks!

Hi @shabaz123,

What do you suggest could be the best way to shut down the stack, or at least to know when the NVM is not being written to? Is there a lorawan_close() type of function?

This is no lorawan_close() function - but would be open to reviewing a pull request to add this feature.

The reason I'd like to do such a shutdown or be able to be sure when NVM is not being written, is because I managed to corrupt the portion of Flash that the LoRaWAN stack uses as NVM somehow, I believe through removing power at an incorrect time. I'd like to first check (or shutdown the stack) that it is not writing to NVM, and then remove power. I have only corrupted it once, but I wanted to reduce the risk of it occurring.

Let me know if you have steps to consistently reproduce this issue.

Also, I was wondering, when does the NVM get written to? Is it when lorawan_init_otaa() is executed, or also at any other point?

From my understanding the NVRAM is written after packets are transmitted.

Hi Sandeep,

Thanks for the feedback! Currently I don't have steps to reproduce it. Thinking about it some more, perhaps the low-hanging fruit is to merely know if the stack is using NVRAM or not, so I've created a pull request with a suggested function, called lorawan_nvm_in_use.

With that function, it is possible for the user application to have code like this:

do {
        sleep_ms(100);
    } while(lorawan_nvm_in_use());
self_poweroff();

Let me know if you think this is fine or not (I have tested it, and it seems fine).
Many thanks!

Currently I don't have steps to reproduce it.

Let's hold off on pull request #29 until we have a way to reproduce this and can verify the fix.