CubeMX support for SD+FatFS+SPI

[John Craven]

Posted on October 10, 2017 at 21:22

I would like to see CubeMX support for SD cards + FatFS using an SPI driver option. Both for MCUs that don't don't support SDIO and also on MCUs that have SDIO but where SPI fits the project better.

FatFS is there as 'user defined' forall.

SDIO option is there where supported.

Why not add SPI option under FatFS?

Seems like would be pretty minor to the follow the templates used in SDIOfor SPI.

Certainly would make it easier to get an stm32 project doing FatFS on SD!

#cubemx #sdio #spi #sd-card Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Tesla DeLorean]

Posted on January 29, 2018 at 23:00

Took deliver of some clean sockets that just need schmart wires to loop into DISCO/NUCLEO boards

https://www.ebay.com/itm/1pcs-NEW-Micro-SD-Card-Module-Slot-Socket-Reader/272798769771

 

http://schmartboard.com/wire-jumpers/

 

[Tesla DeLorean]

Posted on February 07, 2018 at 17:53

Second, cheaper, more compact design supporting SPI attachment

https://www.ebay.com/itm/10Pcs-Mini-SD-Card-Module-Memory-Module-Micro-SD-Card-Module-for-Arduino-AVR-ARM/382224594752

 

Prototyping Products For Schmart People...

http://www.schmartboard.com/

[Tesla DeLorean]

Posted on February 07, 2018 at 23:33

Always been successful with SDIO, both with wire-wrap and schmart wire implementation, and a couple of assorted boards I've worked on, or ported code too.

https://community.st.com/0D50X00009XkYXdSAN

https://community.st.com/0D50X00009XkZe6SAF

Currently got both an SPI and SDMMC implementation working on a NUCLEO-L476RG, the SPI is a bit of a sloth, which is why I usually avoid it. Also had to dig some bugs out of the adafruit_sd implementation.

https://community.st.com/0D50X00009XkgXzSAJ

http://www.st.com/en/evaluation-tools/nucleo-l476rg.html

[Bogdan Golab]

Posted on February 08, 2018 at 08:49

If could share you thoughts about STM32F1 and SDIO/FatFS - did you use HAL drivers or SPL?

Currently I am working on a project where I cannot debug the target - the code is uploaded through my own bootloader (heavily tested).

Just wrote simple SDIO/FaFS initialization code using HAL but quick test shows that the program crashes.

Quick search of this community shows some issues reported to SDIO initialization but not sure now if it is fixed in the current F1 HAL drivers.

Of course I will prepare separate board / SD card setup to investigate it under the debugger but I would like you to share some experience about HAL/F1/SDIO.

Thanks

[Tesla DeLorean]

Posted on February 08, 2018 at 17:33

The F1 is rather antiquated at this point, moved to F2/F4 parts years ago. Most of the original SPL code use byte offsets, and did not support SDHC/SDXC class cards, out of the box. The SDIO interface was only available on a subset of parts, and most used SPI to provide SD card support. Have built code for a couple of F107/F103 boards (SPI/SDXC), and the EVAL boards (SDIO/SDXC).

[Bogdan Golab]

Posted on February 08, 2018 at 19:30

I have STM32 Primer2 where the STM32F103VE is used. It's kind of a device for hobbyist with many nice features. The microSD card reader is already soldered:

http://www.stm32circle.com/resources/download.php?schema_stm32_primer2_1_2.PDF

 

[Tesla DeLorean]

Posted on February 08, 2018 at 19:56

Just checked the part on the Nucleo, unfortunately this doesn't support SDIO, apparently only on the 'High Density' parts, which is rather frustrating.

http://www.st.com/en/microcontrollers/stm32f103rb.html

 

Need to dig through my box of EVAL boards.

Choices of low cost boards with STM32F103VET6 and MicroSD is surprisingly shallow

https://www.ebay.com/itm/STM32F103VET6-ARM-STM32-Minimum-System-Development-Board-Arduino/291549961695

 

[Bogdan Golab]

Posted on February 08, 2018 at 20:17

The Primer2 does not have st-link that's why I developed a bootloader using USB port to upload the code to SRAM (I like running code in SRAM). So the debugging capabilities are only limited to printing the data through USB (CDC_Transmit_FS()). So it seems that I need another STM32F103VE board to debug the code for the SDIO. I used HAL drivers for the code I wrote so far (LCD, MEMs, USB, JOYSTICK, etc). That's why I was interested in HAL drivers for SDIO.

[Tesla DeLorean]

Posted on February 13, 2018 at 03:15

On the L4 Nucleo (80 MHz APB2, 40 MHz SPI) 0.75 MBps read with adafruit code, 1.15 MBps using multi-sector

[John Craven]

Posted on February 13, 2018 at 23:02

Itested the adafruit shield on Nucleo-767ZI,

Used..\STM32Cube_FW_F7_V1.9.0\Projects\STM32F767ZI-Nucleo\Applications\FatFs\FatFs_uSD project in uVision

Settings in the project: 216Mhz core, APB2/SPI_BaudRatePrescaler = 108/8 = 13,5 MHz

Scandisk Ultra 32G card

1MB file,got 356kB/s write rate for 32kB writes, around 238kB/s at 512 byte writes

This included your fix

https://community.st.com/0D50X00009XkgXzSAJ

Based on your numbers above, ichanged the project for

200MHz core,

APB2/SPI_BaudRatePrescaler = 100/2 =50 MHz

and

200MHz core,

APB2/SPI_BaudRatePrescaler = 100/4=25MHz

Big block write stayed same and the 512B wirteswere alot slower.