2014-07-22 07:28 PM
I'm using STM32F4-Discovery for data/debug logging on uSD card. I have found samples in STM32Cube package:
..\STM32Cube_FW_F4_V1.3.0\Projects\STM324xG_EVAL\Applications\FatFs\FatFs_uSDI ported this sample to my project which also works on the F4 Discovery board. I'm writing GPS data & many debug messages to this uSD card whenever they are available in my app.The problems I'm trying to solve are1. If the card is removed while the application is running, how can we preserve the data which is already written to the .txt file on the uSD card. 2. If the card is re-inserted again, how to start logging into the same .txt file to which we were writing before.3. In case of unexpected power off, how can we preserve the data which is already written to .txt file.I'm using the OpenLog ( avaiable at ) for data logging, it works fine even if there is unexpected power is off, data will not be lost.Here is the link to . #stm32cube #usd-card #stm32f42014-07-23 01:35 PM
One of the real problems is that writing the data doesn't update the file system data in the directory, you'd need to periodically flush or close the file.
You might also want to preallocate the file space so all the FAT entries are assigned and written, and then you back fill the data, and truncate later. To restart you either need to hold a value, or be able to navigate through the file to find where you stopped. You might want to add your own fsck/chkdsk type functionality to recover cards where data/fat entries are present, but not reflected in the directory. Finally, one really might want to look at having some amount of backup power, and the ability to detect if the primary supply is going down. Once sensed you should commit all pending data, and close gracefully, before shutting down. See also the Card Detect pin and if you can see that is changing before the card is removed to the point the connection is lost.2014-07-24 05:37 PM
Thanks. To some extent I have solved the problems 1 and 3 written above, using card detect pin, f_sync function periodically. Also I was able to create & write to two files ( debug msg, data log).
Still experimenting the code on the problem 2.2014-07-25 08:16 AM
Is the problem with remembering the name or the last write location?
Seeking to the end of a file shouldn't be that hard. For a file name perhaps you could have your own private tracking file, or use NVRAM to store things, or structures as space permits. Depending on the naming, or support for timing, you could enumerate files in a directory and find the last one.