-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
store counter of restarts in NVS (Non-Volatile Storage) #779
base: master
Are you sure you want to change the base?
Conversation
Ludovic, can you please elaborate on your reasons to choose the esp-idf NVS system over our config store NVS system? While we did reserve that partition (I think it's used by the Wifi blob?), I didn't see any advantage in actually using this up to now. I once though it could later be useful for values needed early in the boot process. You currently place it right before the actual config store init – is there a reason this needs to be done that late? Btw, is there also a reason why Thanks, |
Regarding the choice NVS vs config, I did not give it a complete thought I'm afraid. It may be a (wrong ?) gut feeling that NVS would be more low-level, and inaccessible (protected from modifications) from the user. A kind of fire and forget. Indeed it's used mainly for the Wifi blob at the moment - when I remove the initialisation, Wifi fails with error. I tried to make it initialized in the constructor, but it did crash or fail (don't remember exactly the details), and so I thought it had to be there for a reason and that I should not mess with it. If you're OK for continuing to use the NVS, I'll try to give another go at the initialisation sequence in order to have it as early as possible. Let me know. |
I'm fine with using the NVS. Having this counter outside the config store to exclude it from user access & backup/restore is a valid reason. Thinking about this, we also still see occasional store partition corruptions, which maybe do not occur on the NVS without the FAT FS layer. It would be nice to have this early in the boot process, but there currently is no need for this, so don't put too much effort in it if it doesn't work easily. Getting issues from doing the init in the constructor may mean it's designed to be used in FreeRTOS mode only. |
OK so when I move the init in the constructor, it aborts with a mutex-related assert :
Stack trace (long)
It may mean that during initialisation, a few things are missing, or another part is lock the mutex ? |
I have a question on why this is required? Is it not possible / easier to simply look at the files on SD CARD and set the next counter as the highest numbered log file + 1? Apart from the issue of trying to keep two separate things (the log files on SD card and the counter) synchronised (especially when the SD CARD can be easily changed), we also have to be aware of the limited number of write cycles on the on-board flash (and try to minimise writing/logging to that wherever possible). |
Hi @markwj, Let me try to work on the "find the highest numbered log file" + 1 thing, and I'll keep this discussion updated with a comparison between the two approaches. |
It means the esp-idf NVS needs FreeRTOS running, so there will be no way to use this early in the boot process.
…or maybe as I suggested earlier, apply the log task scheme of writing to a specific file name and renaming that on cycling? |
05cb95b
to
13b1944
Compare
Regarding post-renaming vs creating the log file with the proper name right from the start, I think I prefer having the name right. Ultimately I think this is not much of an issue, but I'm always trying to imagine worst-case scenarii such as a sudden power loss during can log. Regarding the naming - you rename the file with a timestamp, which is the right thing to do. However in my case I fear that for the first few files my module would still live in the past - it does timestamp my files in the 70s and the 80s at the moment (Network disabled, GSM disabled, GPS slow slow to receive time). So I prefer to offer the option of an incrementing counter (with appended timestamp):
(first counter is number of restarts; second is number of cyclings for this "file") |
13b1944
to
d57d003
Compare
d57d003
to
6c397f8
Compare
6c397f8
to
0d63028
Compare
0d63028
to
0482f8e
Compare
87f42bf
to
fe88aeb
Compare
Signed-off-by: Ludovic LANGE <[email protected]>
fe88aeb
to
4ce56ac
Compare
In preparation of openvehicles#748, this counter will serve as part of an "unique" token in the log file name ; ensuring that after a reboot we will not overwrite an existing log file. The counter is stored in NVS, and is incremented at each class instanciation; which should roughly translate to every reboot. (Don't know about the deepsleep for the moment). The counter will reset to 1 after 99.999.999 restarts, which should gives us plenty of time. Signed-off-by: Ludovic LANGE <[email protected]>
4ce56ac
to
66d04ed
Compare
In preparation of #748, this counter will serve as part of an "unique" token in the log file name ; ensuring that after a reboot we will not overwrite an existing log file.
The counter is stored in NVS, and is incremented at each class instanciation; which should roughly translate to every reboot.
(Don't know about the deepsleep for the moment).
The counter will reset to 1 after 99.999.999 restarts, which should gives us plenty of time.
Signed-off-by: Ludovic LANGE [email protected]