This issue is becoming bad enough that I need to seek out a solution.
I have a simple product that uses the RCM3700. I’ve been making them for 4 years.
I save the program, and data in files in FLASH memory.
More and more these days I get units that just seem to lose all or some of their flash data. I’ve seen several generations of RCM3700 come and go. But the problem remains.
Anyone know if there is a known “issue” with the flash?
The problem seems to occur during power cylcling. I had one unit (that I tested before shipping) just fail to boot once it had arrived at it’s destination. I’m assuming it lost it’s program.
My flash updates are infrequent, so not likley to coincide with startup power glitches. But I’m wondering if the RCM3700’s power/reset circuitry protect the FLASH writes in any way. What can be done to avoid losing flash from a corrupted write?
I am having issues with the serial flash on the RCM3720. If I cycle power without the backup battery and then I lose huge chunks of my files I had stored on the serial flash.
I have the serial flash formatted as FAT. Also, the files that get whacked will not let me overwrite them so I have to reformat the flash partition. Makes the serial flash unusable.
I am looking into getting it repaired and/or use SD chips. They can more easily be replaced.
My understanding of things is that if you are using the fat file system you need the battery backup. I seem to recall something about this in the docs. I know there is a buffer reserved in the battery backed RAM for the FS.
Okay, progress. I think this is all software. In int http_defaultCGI(HttpState * state); (HTTP.LIB) it writes files to the FAT serial flash partition. It does not at any time flush the cache buffers to the flash. So I did this here:
case CGI_END:
…
sspec_close(spec);
//file is closed flush flash cache buffers
fat_SyncPartition(PARTITION_A);
This seems to have done the trick. It makes sense as the manual says those flash cache buffers are battery backed. So now I do not need the battery in to maintain the files between power cycles.
Now this is only done after the defaultCGI function finishes writing to the file. This hopefully should not cause excessive wear on the flash device.
petermcs,
Thanks for the info. You are right it is the cache that battery backed, but for file storage it should not be volatile at all. An explicit flush allows it to be saved without the backup battery. So I forced it to write the cache to flash after each file is written. Works great without a backup battery in place. No corruption!
I don’t know if this will help the OP of this thread, but maybe it will help someone.