I am trying to be able to read and write to a microSD card from a stm32h7 based chip, and am currently having issues with mounting the disk.
If I format the disk on my windows laptop, then I am unable to mount the disk on the microcontroller side.
If I format and partition the disk on the microcontroller side, the mount works just fine, however, plugging the SD Card back my laptop, Windows says that the drive is not readable, and I must format it first.
Code flow wise, I call the FATFS functions in this order: FF_Partition → FF_FormatDisk → FF_Mount → FF_FS_Add
My apologies, I should’ve added more information about the debugging process.
Testing wise, I have a 4GB MicroSD HC card, it’s been formatted on a windows laptop to FAT32, and contains 1 text file with helloworld inside.
This morning when I ran more tests, I found that for some reason the mounting was working, and that specifically the section of code within ff_ioman.c where pxPartition -> usBlkSize % 512 != 0 was passed. That is to say that the usBlkSize value was 512. I ran a few more tests, trying to get my pathing right, when suddenly the mounting error returned.
Here, the partition block size becomes 2, and the FF_ERR_IOMAN_INVALID_FORMAT error is thrown.
Furthermore, within the FATFS in memory, upon completing FF_PartitionSearch, within the memory, I am seeing Disk error Press any key to restart.
A block size of 2 would just be wrong. I can’t imagine Windows doing that. The question is are you getting corrupt data being read, or corrupting the data after being read. The confusing thing is that should change based on who formatted the drive (unless you made changes in the program to do that).
So, currently in my code, I am not formatting the drive. I am getting some card info from my SDMMC, then mounting the card. On the windows side, I am formatting the disk, creating a new txt file, then using the “Safely remove hardware and eject disk” feature. I power off the microcontroller, plug in the SD, then power on to test. Within all of those steps, I do not think the data is being corrupted upon entering the breakout board. After I see the above errors with mounting, I can pull the SD Card out, and plug it into my laptop, and the created text file still exists, and is readable. So the data on the card, is able to be read by Windows.
Therefore, I don’t think the data is being corrupted at all. Windows sees the data cleanly.
Upon partitioning the drive, within the above mentioned FF_PartitionSearch command, the disk is showing an error. I suppose it could be something with the way I am setting up the partition search?
Sure, so I don’t know if it’s an “issue” from within the partition search function or something else. The code flows through the partition search, and provides me with the output of 1 (since I am formatting on windows, I would expect this to remain 1, right?).
However, within the partition search command, there is this FF_GetBuffer function:
Upon the return from this function, I see the contents of pxIOManager->pucCacheMem which are the outputs on the right side of the window. At the 6th line we can see that it recognizes the FAT32 file system, however, at the bottom of the screen, you can see it states that there is a disk error and to “press any key to restart”.
My current belief is using the Windows File Explorer tool to format a SD Card to FAT32, does not partition the drive in a way that the FreeRTOS + FATFS library likes? Is there another tool that people have used?
Is this an off-the-shelf SD card, or industrially certified? If the former, truly anything can happen, and you may be wasting many many hours chasing down a problem in the card. BTDT. Since you write that the problem is intermittent, that strongly suggests you are hunting after a ghost. A simple test is to replace the SD card with another one. You may be experiencing totally different problems or none.
I can only repeat what I wrote from own experience several times here: Do NOT allow your customers to use SD cards that you have not tested and certified for quality control. The stuff that you buy in super markets and even radio shack is not well quality tested, it is disposable consumer penny ware, EVEN if there is the name of a reputed company stamped on it. Go for industrially certified SD cards only.
To my understanding, the contents of pucCacheMem is data read from the SD Card. Therefore, since I am formatting the data on my laptop, then immediately reading from it via my nucleo, I’d imagine there shouldn’t be any Disk Errors within this memory.
Furthermore, reading from pxIOManager within the FF_Mount function, when trying to get the block size, I am seeing the value of 2, rather than the expected 512. A disk error in memory would likely also tie into why the block size is incorrect, and therefore, failing to mount the disk. That’s why I care about what is being shown within the pucCacheMem variable, let me know if my understanding is incorrect there, I am still very new to using FATFS.
I have used 2 different SD Cards, one which is a standard off-the-shelf SanDisk ultra, and a second which is an industrial certified Apacer 4GB Micro SD Card.
that is a good shout though, and I’ll make sure the SD Card selection to more narrowed to only industrial certified SD Cards going forward. Thanks!
Thanks Carl, I will take a look now, it’ll be good to verify these SD cards. I currently only have a RPi 4B, so I think I will need to do some minor tweaking to get this working!
Can you show the command line you are using to format the disk on Windows for use in the MCU. If you are using the windows “format” command you will probably need to use the /FS:FAT or /FS:FAT32 option.
So I have been using the windows explorer tool for that, like so:
However, I am looking into using the SD Card Formatter by SD.
When formatting using this, that same pucCacheMem just shows all 0s, and says the blockSize is 0, rather than 512. Seems like it might be because the SD Card Formatter does not create partitions? Still investigating there…
Another thing to note, when I format the SD Card using the microcontroller, then plug it into my laptop, then open the disk management utility, it says the card has been formatted to RAW file system.
I run essentially the same code on a NUCLEO-L4A6ZG, using both the onboard SDMMC and SPI interfaces to SD cards. That is, the test code doesn’t change. Obviously, I’m using different Media Drivers than on the Raspberry Pi Pico.
Note: these are more or less standalone tests. A few of them are borrowed:
