search

Lora-net / LoRaMac-node

Reference implementation and documentation of a LoRa network node.
Other
1.87k stars 1.09k forks source link

NVM context management #1136

Closed Adamzat closed 3 years ago

Adamzat commented 3 years ago

Hi all,

In OTAA mode, only DevNonce and the JoinNonce are needed to be stored in EEPROM after the Join success. The LoraWan Stack (4.5.1), reads and writes “All data” very frequently (about each Uplink). All data takes about 1452 bytes. Our products use STM32L1 and the maximum number of cycling (erase / write) of the EEPROM is about 300Kcycle. This number can be easily reached (300K frames, for not powered devices).

Is there a possibility to enhance this feature (saving only needed data + reducing the frequency)?

And regarding the ABP mode, is there a possibility to reduce the frequency of storing all data (for example each 100 or 1000 uplinks) ? What could happen if we lose the context in ABP (reset, etc.) ?

Thank you for your reply.

mluis1 commented 3 years ago

This subject has already been discussed on several Issues/Discussions.

In conclusion, we have already analyzed and tried to reduce the amount of data to be stored on the NVM memory. The current amount is what we believe to be the minimum.

Nowadays, the MAC layer notifies the application layer to only store what changed since last notification. In the provided example we decided to store each time the MAC layer notifies the application layer. However, nothing prevents you to not do so (not recommended).

The full amount is only written one time (First boot or when the NVM data is reset). Then after every uplink around 80 bytes (EU868) are stored. Depending on MAC commands sent by the Network Server the amount can be bigger. The biggest amount of data being stored is related to the secure-element soft emulation (keys, nonce, etc...). The secure-element data does not change very often. In case an hardware secure-element is used the amount of stored data will be greatly reduced.

One of the reasons we decided to update the NVM after each uplink is to be able to power off the end-device and just continue the normal operation once powered up (without joining the network again).

In the provided example we use the MCU internal FLASH memory because it is the only non volatile memory that is available on this project supported platforms examples.

There are a few possibilities to increase the NVM life time

In the future it would be nice if you could post this kind of questions on the project Discussions tab. It is a better place to engage discussions and then we can agree if it is an issue or not. If you don't mind I move this issue to the Discussions tab.