Stopping Corruption of SD Card when OTA Flash

I am looking for advice about how best to stop an issue that I have noticed recently that when flashing devices with the latest software quite often the event log write to an SD card is getting interrupted and this is resulting in a corruption of the file which after restart means I have to delete the file and re-create it. Thus potentially I could lose events which is what the log was designed to prevent!

I am looking for a method to complete all SD card write commits before the flash starts and thus hopefully avoid file corruption and the need to junk the event log file.

I have seen this in the OTS Updates section of the photon documentation:

Indicates if there are OTA updates pending.Note: Currently this function does not do anything useful, since it only returns true once the OTA update is already about to kick in. 

The explanation isn’t very encouraging as to its usefulness. Any ideas from the community?

You can disable OTA updates while you are about to enter a critical block and re-enable when done.
System.updatesPending() does not do anything useful while updates are disabled, since this prevents the update to actually kick but only after that System.updatesPending() would return true.
On the other hand, when updates are enabled and an updated has already started System.updatesPending() should return true and hence provide you with some means to prevent entering the critical block. You may lose some data in the process but should not run the risk to corrupt your already stored SD data.

In order to become fully useful System.pendingUpdates() should even work while updates are disabled to provide a way to only enable updates when there actually are updates to be applied and it’s safe to do so in respect to the application state. But that would require some tweaks on the backend as well.
The name of the function would suggest that it might have any knowledge of the presens of an update on the cloud side before it’s actually going to be applied, but that’s not the case. Currently it’s only an “after-the-fact” info.

I have already opened several issues regarding OTA updates

1 Like

Hey, thanks for the quick reply, a few things for me to try here. I will check out the issues regarding OTA updates.

UPDATE - this has fixed the issue I was experiencing with the log file getting corrupted during OTA flash. However, I am still getting the occasional corruption when a device is unpowered and later repowered. Is there any way to make a write that doesn’t leave the file corrupted or a way to fix files?

1 Like

Are you leaving the file open? Are you calling the sync() method of the FatFile object periodically?

If you don’t close the file or sync, SdFat only writes out the data at 512-byte block boundaries. You don’t want to sync too often as it may slow things down, but in SdCardLogHandlerRK I found I could sync after every log entry write and the performance was still OK.


I do close each time I write/update. I assumed the issue was power down after file open for write but before file close.

Hey @armor,

I am seeing the same issue on my end, can I ask how you delete the file on restart, it might get us out of a hole while I implement something more permanent.

I use this sd.remove(eventlog); to delete the event log file but do this before the restart, that way on start-up if the file is not found the system will create and initialise it, otherwise if it exists then assume that the file is good and should continue using it. I also have a daily ‘grooming’ whereby the event log file is truncated so that it does not continue to grow forever. I also wrap everything with the SD card with System.disableReset(); and System.enableReset();. Hope that helps.