2025-01-08 02:12 PM
Hi
I'm trying to connect an SD card to my Nucleo U5A5ZJ-Q board using SDMMC peripheral and use it with FatFS library. When I use 1GB card and 4 bit mode, everything works fine. By "works fine" I mean that:
1. it passes this FatFS test: http://elm-chan.org/fsw/ff/res/app4.c
2. it is able to create a working text file.
But there are 2 problems:
1. 1 bit SDMMC mode doesn't work. When I'm trying to use it, the FatFS test fails at an SD card write. After clicking around in STM32CubeIDE debugger I found that there is a CRC error in SD callback being set as status, which then leads to a timeout and test fail. This problem isn't critical, because 4 bit mode seems to work, but it worries me a bit.
2. 16GB and 32GB cards don't work. They get a bit further (to reading), but fail in a simmilar way (SD callback -> CRC error -> timeout -> test fail). I haven't been able to test 2-8GB cards yet. This is more of a problem, because it's getting harder and harder to get such small capacity cards.
The whole project is attached below.
Ideas, anyone? Thanks in advance.
Adam
Solved! Go to Solution.
2025-01-23 02:37 PM
I've re-run the test from that .xyz website I linked earlier with mount 0 and 1.
In 4 bit mode both are working.
In 1 bit mode I get FR_NO_FILESYSTEM in both cases.
With Chan's test (link in original post) 4 bit mode passes without problems. 1 bit mode fails - CRC error in write callback.
2025-01-24 12:11 AM
So be glad, 4 bit mode working fine.
And 1 bit also on read, but problem on write - if your info is correct.
If you want find the reason for this, you have to find out : is hardware or software the problem.
Because 4 bit mode working, which is much more problematic regarding the connection, i would look at the software first.
So you could try to use a more recent version of the fatfs , see on Mr. Chan's downloads . (STM still have 2017 version...8 y old now.)
And what you use: with DMA - or not ? Try both.
2025-01-24 12:07 PM
>So be glad, 4 bit mode working fine.
Yeah, right now I only need 4 bit mode to work. I'm curious as to why 1 bit mode doesn't work, but I don't know if it's worth it for me to find out due to how much time I'm spending on this. Maybe the connections are still too long? But again, thank you very much for your help!
>And 1 bit also on read, but problem on write - if your info is correct.
The Chan's test stops on writing. Reading is after that, so it doesn't get there.
The .xyz website test fails on f_mount with error 13 (FR_NO_FILESYSTEM)
>So you could try to use a more recent version of the fatfs , see on Mr. Chan's downloads . (STM still have 2017 version...8 y old now.)
I've updated FatFS to 0.15a w/patch 1, still the same.
>And what you use: with DMA - or not ? Try both.
I've been using DMA before. Changing BSP_SD_WriteBlocks_DMA to BSP_SD_WriteBlocks doesn't help.
2025-01-24 12:51 PM
So maybe something coming from your hardware - but what then ? You could try with a really short connect - just to know. And making pin speed lower and higher - any change ?
btw
As i said, 1 bit (in my tests also) more easy , to get it running; worked on all cpus, i used: F401, F411, H563, H7A3, H743, H733 .
H563 here should be similar to your U5 , same series with M33 core. Just here big problem: sd didnt work at all, because the (generated) init for the sdmmc set pin speed always hi , with no pullups. Didnt work.
After i found out , changed it , then - it worked.
/* USER CODE BEGIN SDMMC1_MspInit 1 */
GPIO_InitStruct.Pin = GPIO_PIN_8|GPIO_PIN_9|GPIO_PIN_10|GPIO_PIN_11
|GPIO_PIN_12;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_PULLUP;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_MEDIUM;
GPIO_InitStruct.Alternate = GPIO_AF12_SDMMC1;
HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);
GPIO_InitStruct.Pin = GPIO_PIN_2;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_PULLUP;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_MEDIUM;
GPIO_InitStruct.Alternate = GPIO_AF12_SDMMC1;
HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);
/* USER CODE END SDMMC1_MspInit 1 */