Basically it looks to me like every change that happens to the LoRaMacNvmData_t structure is synced to one page of flash??!!
So essentially this means that the 10K flash endurance of the STM32WLE5 will be quickly reached. Every devNonce, joinNonce, and frame counter change is synced here. This seems disastrous for numerous reasons, one of which what happens if power cycled during flash page write, and there seems to be no backup?
Hopefully I’m missing something here, help me out.
Can you clarify what is saved to flash and how often? Or if wear leveling is used?
I’m not clear on rakwireless code, but newer lorawan code and spec basically specs this to happen.
It looked to me like the structure checks crc and flags any change to be saved, and there is only one page used to do so, so if power cycled at the erase point the config would be lost.
RAk3172 saves only LoRaWAN/LoRa P2P setting (credentials, region, frequency, …) to the flash. It is only written if changed with AT command or with API calls.
Thank you, also I did confirm this before I saw your answer by using SWD pins to readback and compare binaries.
If for some reason you decide to support Lorawan spec 1.1.0, you might consider allowing at command persistence storage on host mcu or fram on package, otherwise flash endurance would come into play.
If you’re using my repo, it’s 100% the ST firmware port, and I do suspecting an issue with this in the ST code. I suggest asking at the ST forum - and you’re welcome to open a discussion on my GitHub repo to track that.
I did not notice that frameCount is being written on every change. Every join really shouldn’t be a major issue in deployment.
I vaguely recall this behavior is specific to the v1.0.4 variant of the build (selected in Cube).