Unable to mount a drive that is formatted on windows

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_PartitionFF_FormatDiskFF_MountFF_FS_Add

Is this an issue that others have come across?

Thanks in advance,
Vink

You might try stepping with a debugger through the mount operation to see what it is complaining about.

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.

image

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.

tldr; I believe the error is coming from 1 of 2 possibilities.

  1. When windows does a quick format it doesn’t format the disk in a way that is compatible with the FreeRTOS + FATFS Library.
  2. The wires between the MicroSD Card Breakout, and the nucleo board could be too long (They are about 5cm in length).

Would anyone have any other insight into what a bad block size reading could mean?

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?

Is it possible for you to step through FF_PartitionSearch and see what is causing the error?

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?

Why do you care about the content of this memory? Is this causing any problem for you?

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.

2 Likes

There are some tests you can run. I have a little collection of them at

app4-IO_module_function_checker.c can be particularly effective at finding bugs in the Media Driver, but it will wipe out the format on your SD card.

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:
image

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:

Compatibility Checker for Storage Device Control Module (app4-IO_module_function_checker.c) bypasses the file system entirely and drives the block device driver (Media Driver) interface directly. This makes driver testing and debug much simpler.