Internal fastfs file gets corrupt some time after re-power.

[snahmad75]

Hi,

We found internal fatfs is not very resilient. It could be two threads are access file simultaneous.

It is just small json of 500 bytes I need to save. After hard re-power. It corrupt the file some times.

We found NVS is more resilient power down and brown out as compare to internal fastfs

Saving to SD card is also more resilient .

We are no planning to save these small json in NVS and another copy on sd card as backup. Is this good solution?

Thanks,
Naeem

[jcsbanks]

Are you using performance or safety mode? How long after closing the file is the power being cut? Are you unmounting?

[snahmad75]

Are you using performance or safety mode? How long after closing the file is the power being cut? Are you unmounting?

I am using safety mode. never check power cut after how long. I am unmounting as well.

Any idea? I am going to use NVS and backup on sd card as files as well. we found ad card and NVS is more robust for power cut.

[snahmad75]

It could be we have multiple Tasks/threads accessing fatfs simultaneously. Do I need mutex. I access different files. Is fatfs is thread safe for internal fatfs and sd card fatfs.

Now We are using NVS. Is NVS read/write or commit is thread safe

[ESP_igrr]

Yes, FATFS is thread safe as long as the threads access different files.

NVS is also thread safe (all operations are serialized).

If you can enable debug log level and post the logs (before powering off the device, and after powering it up again) then it might help figure out where the issue is.

[snahmad75]

Yes, FATFS is thread safe as long as the threads access different files.

NVS is also thread safe (all operations are serialized).

If you can enable debug log level and post the logs (before powering off the device, and after powering it up again) then it might help figure out where the issue is.

ok, I will try out later. unfortunately debug level log generate too much logs for adc voltage reading. very tricky to capture only relevant logs.

[ESP_igrr]

You can silence any specific log tag, in this case "RTC_MODULE", as follows:

esp_log_level_set("RTC_MODULE", ESP_LOG_NONE);

(https://docs.espressif.com/projects/esp ... is-library)

[snahmad75]

You can silence any specific log tag, in this case "RTC_MODULE", as follows:

esp_log_level_set("RTC_MODULE", ESP_LOG_NONE);

(https://docs.espressif.com/projects/esp ... is-library)

This works. thanks.

[snahmad75]

Sometime fwrite fails. It writes zero bytes so generate emty file.

I am using fopen(, "wb")

Is this correct flags for file write.

I am using few months old master branch of version =3.2

now I downloaded official release of version=3.2
I will try it again.

[jcsbanks]

Internal flash writes during large partition updates from OTA, or sometimes even small files with FATFS can cause problems with the CAN driver and high resolution timer callbacks resulting in interrupt watchdog timeouts, so I've preferred to refactor my work to use a form of RAM disk where a map of strings vs byte vectors is stored in PSRAM rather than save extensively to FATFS at run time, and adding vTaskDelay to OTA updates code and am choosing to disable CAN completely during some operations and considering returning to a previous method I had of rebooting into the factory app to do OTA updates whilst doing nothing else with even soft realtime requirements on a busy CAN bus. Until I started writing to internal flash I had not appreciated how disruptive it can be to a running system's realtime responsiveness, where a busy CAN bus barely tickles the ESP32 normally. Not sure if related to your work, but from your previous posts it sounds like you are doing similar things with CAN bus, networks and file systems.

ESP32 performance is quite amazing in all respects for what it is and what you can achieve in a fast booting tiny system, but flash writes are the slowest and most intrusive thing by far that I need to do.