cancel
Showing results for 
Search instead for 
Did you mean: 

Is a 32GB MicroSD HC 1 still a micro SD HC for stm32F446RE ?

papageno
Associate III

Dear experts,

My SanDisk Extreme 32GB V30 MicroSD HC 1 is not recognized by HAL.... SDIO 4 bits .Stay stuck in the SD_Init...Is that SD card not compatible with the standard implemented in HAL and the MCU ? Time is short and I cannot dig in the lower layers and the SD specifications.

Thank you for your help.

Pap

1 ACCEPTED SOLUTION

Accepted Solutions
papageno
Associate III

Thank you very much Clive.

You are right, using a micro SD card can be a boring game playing with different parameters (clock divider, electrical parameters and so on). I was a little disappointed when I noticed the software stays stuck in the HAL SD layers on SD response. Unfortunately, I cannot spend much time on a long bug hunting, so i will come abck to 8GB from SanDisk which works well. The most amazing thing is that I succeeded to make the 32GB card work using the step by step in debug mode and let it run after the init was passed. Incredible , may be satisfying for some test but not realistic in normal life :). I will probably try to find a 16GB but I think that you are right, the fast card are a real golden unit to test the electronic design, I will keep that in mind for my next board design. Still a few electronic parameters on the sdio pins to play with to close this chapter for me.

Just another quick question: what library do you use for SDIO ? HAL seems not so reliable to me (I did not see any LL libs) and I wish i could have strong read/write routines to validate the sdio transfers, I need to quantify the transfer times.

Again a warm thank for your sharp advice, that's a great help for me.

View solution in original post

6 REPLIES 6

As a general rule I can't say I've had issues with SanDisk SDHC or SDXC cards. I've used Extreme and Extreme Plus ones of 32 and 64GB for sure on STM32 implementations. As well as other SanDisk cards pushing out to 200 and 400GB

Support for Ultra modes might be a bit sketchy, but I don't think you're likely to be using lower voltages or DDR modes on an F4 as the SDIO simply doesn't support that.

The HAL code isn't particularly well tested/validated, as you wander off into the corner conditions you're apt to find cards that break things. Usually that's customers using weird off-brand cards of dubious origins rather than authentic SanDisk ones, but when you get fast cards they can also test your electrical implementation, where slew-rates, ringing, line-lengths, and transmission-line theory start to bite.

If you see anomalies in lab testing, best to root-cause the issue, as the problem usually comes back on the tech-support staff.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
papageno
Associate III

Thank you very much Clive.

You are right, using a micro SD card can be a boring game playing with different parameters (clock divider, electrical parameters and so on). I was a little disappointed when I noticed the software stays stuck in the HAL SD layers on SD response. Unfortunately, I cannot spend much time on a long bug hunting, so i will come abck to 8GB from SanDisk which works well. The most amazing thing is that I succeeded to make the 32GB card work using the step by step in debug mode and let it run after the init was passed. Incredible , may be satisfying for some test but not realistic in normal life :). I will probably try to find a 16GB but I think that you are right, the fast card are a real golden unit to test the electronic design, I will keep that in mind for my next board design. Still a few electronic parameters on the sdio pins to play with to close this chapter for me.

Just another quick question: what library do you use for SDIO ? HAL seems not so reliable to me (I did not see any LL libs) and I wish i could have strong read/write routines to validate the sdio transfers, I need to quantify the transfer times.

Again a warm thank for your sharp advice, that's a great help for me.

papageno
Associate III

Clive,

I know you were already asked that question 1 million times but what are the conditions you had to get high transfer rates (around 10Mb) with stm32 ? To write 512Bytes it takes me 1300µs at best (around 3.5Mb/s in polling on sdio 4 bits, no pullup on signals with a sdio at 45Mhz and a clock divider set at 4). Thanks in advance

Write more data per transaction. Typically multiples of 8kB work well. There are other things, but writing more data is going to be the lowest hanging fruit.

If you feel a post has answered your question, please click "Accept as Solution".

512 Byte single sector is always going to be pretty poor, 32KB is the typical sweet-spot I try to hit, via aligned f_write() or f_read() in FATFS

I think 8KB is fine too, it really depends on how much memory you can commit to buffering. A Cluster is the maximum size FATFS will access in a single read/write operation.

Doing many small/misaligned f_write() will be very bad.

MicroSD cards are supposed to be rated to a minimum 50 MHz wire-speed, at DIV2 most F4 should be able to get at 24 MHz wire-speed. I'd have pull-ups at the card interface for the data/cmd pins, and I'd ease off on the slew-rate at the STM32 side, no good reason to bang the short lines with 85-100 MHz edges.

I'd expect 5-6 MBps for writes

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
papageno
Associate III

Thank you Clive, your helps and expertise are really appreciated.

I guess that FatFs uses the DMA transfer. My application is a little tricky with data to read from SPI at 2.4Khz that has to be saved on SD card through sdio and I cannot miss one spi data :( . As you mentionned I will try to buffer and commit. I really do not know if I can have a kind of process saving the data in the background and be interrupted by my spi transfers or if I must use freeRTos .... I have to try.

Best regards,

papa