File corruption after eMMC formatting

[Pramod K.G.]

Hi all,

I am using cubeMx code base for interfacing eMMC with controller STM32L496QGI6. With the support of FAT FS, I could write/read files to/from eMMC. But I am having two issues.

#issue 1. Getting issues after formatting emmc from the device( by using "f_mkfs" api). Every time the files written to emmc after format is getting corrupted and this has been verified by mounting emmc as MSD( care taken about the unmounting of emmc before initializing the USB MSD stack). Also it is taking long time to detect on PC and some times it won't detect. I am doing a processor reset after every USB disconnection from PC( it is a requirement). Interesting thing is that from second USB plugging on wards(after formatting) file is showing correctly on PC.

Eg.

1. File content just after formatting and plugging device to PC :

øÿÿÿÿÿÿÿÿÿÿÿÿ

2. File content on second USB plugging :

USB initialized ( on second connection this string looks readable, earlier it was øÿÿÿÿÿÿÿÿÿÿÿÿ)

USB initialized

Same behavior is also seeing when formatting from PC.

#issue 2. After renaming a folder from PC the contents inside that is not listing, I mean there is nothing inside the folder.

But if I reconnect USB, I can see the renamed folder and its contents. As mentioned earlier I am doing processor reset after very USB disconnection.

Can anyone help me to resolve these issues

Thanks in advance.

Pramod. 

[Tesla DeLorean]

Sounds like your IO routines aren't working properly. ​

[Pramod K.G.]

Hi Clive,

Thanks for the response.

'IO routines aren't working properly', can you please explain in detail?

Please give me a picture of exact issue and also provide the driver layer to be debugged?

BR,

Pramod

[Tesla DeLorean]

In the most basic sense, the block read/write functionality must return the correct/expected data. You'd probably want to instrument those routines to determine the access patterns, and to sanity check the operations such that the writes create a CRC/checksum you can later compare against the same data returned by the reads.

For things taking a long time, you're going to want to benchmark the read/write operations to determine if those are the source of the slowness, and look at any timeout or error status returned.

I'd perhaps instrument the DISKIO layer of FATFS, and review the performance of BSP_SD_ReadBlocks,   BSP_SD_WriteBlocks and DMA variants.

[Pramod K.G.]

Hi Clive,

I will experiment the things you mentioned and get back. But I would like to remember you few things

1. Issue 1 comes only after formatting the emmc by using the FAT FS api. Current firmware flow is shown below
   1. Format emmc and then restart processor when we receive a format success
   2. On boot-up device creates two files on emmc
   3. Mount device on PC as MSD( Un-mount FAT FS and install USB MSD driver)
   4. Files should be corrupted.
   5. Unplug device( Processor will get restarted)
   6. Plug device to PC again after booting up and open the files
   7. Now files looks okay. Items shown as corrupted in the previous plugging looks okay now.

Issue won't come if I skip step 1. Please let me know your comments on this.

BR,

Pramod

[Tesla DeLorean]

If using f_mkfs() make sure you have adequate buffering. You should only need to format an eMMC that is initially blank, I would not reformat repeatedly.