SD card via SDIO on STM32F4 based builds

So I've gotten my project to a point where I can bring up the primary function and run some basic autonomous cellular demonstrations (I'll pop that code up into the projects section shortly here), and found what needed to be adjusted for 16Mhz operation. However, now that I've got that running I want to try and get my major peripherals up and usable. One of them is an SD card, which unfortunately is connected via SDIO, and I can't get a successful compile.

Adding this to my board file:

  'SD' :  { 'pin_cmd' :  'D2',
            'pin_d0' :  'C8',
            'pin_d1' :  'C9',
            'pin_d2' :  'C10',
            'pin_d3' :  'C11',
            'pin_clk' :  'C12' },

It matches the HY, conveniently.

Makefile info:

else ifdef T2_STM32F4
EMBEDDED=1
USE_FILESYSTEM=1
USE_FILESYSTEM_SDIO=1
DEFINES += -DUSE_USB_OTG_FS=1
BOARD=T2_STM32F4
STLIB=STM32F40_41xxx
PRECOMPILED_OBJS+=$(ROOT)/targetlibs/stm­32f4/lib/startup_stm32f40_41xxx.o
OPTIMIZEFLAGS+=-O3

I see this in the jsrap_fs.c file

It is currently only available on boards that contain an SD card slot, such as the Olimexino and the HY. It can not currently be added to boards that did not ship with a card slot.

But I know that it's possible to use the USE_FILESYSTEM=1 on the STM32F4DISCOVERY with added on SD card slot (saw the thread noting it), but I guess before I continue digging in the wrong areas of code I was just curious if this was even possible in the current build, or what I'd have to modify if it isn't.

Running a make with one or the other compiles, it's just not happy with both defines on an STM32F4 based build.

Gordon is planning to provide a facility to use the SD Card on any pins without having to recompile: https://github.com/espruino/Espruino/iss­ues/427

The issue is probably that the SDIO driver is designed for the STM32F1 parts, and you're trying to use in on an STM32F4. You could try and change the code so that it would handle STM32F4 too, but that might be quite hard work.

Otherwise as @DrAzzy says, I'll be including the ability to use the SD card on any pins. It won't be SDIO (in fact it'll just be software SPI if you haven't got the SD card connected to a hardware SPI port), but it should work well enough.

Otherwise as @DrAzzy says, I'll be including the ability to use the SD card on any pins. It won't be SDIO (in fact it'll just be software SPI if you haven't got the SD card connected to a hardware SPI port), but it should work well enough.

Bitbanged SPI is a nice workaround for pre-existing hardware, and would work pretty well I'd bet. I don't suppose there's any ETA on beta firmware for that is there? If it's remotely close I'll just move to the other peripherals and hang tight.

The issue is probably that the SDIO driver is designed for the STM32F1 parts, and you're trying to use in on an STM32F4. You could try and change the code so that it would handle STM32F4 too, but that might be quite hard work.

Yeah I spent quite a while looking at that today and trying to adjust the sdio_* files and various includes to use a discovery board SDIO example, but no real luck yet on that. I'd imagine with the DiscoveryBB using SDIO I won't be the only one to ask though. I should be able to mainly focus on these files for that, right?
diskio
sdio_diskio
sdio_sdcard
ff

Yes, hopefully the only stuff you should actually need to change is sdio_* - I believe the rest is pretty standard ChanFS filesystem code.

I'm not 100% sure when the SD code will be done. The plan is to get it finished by April when the boards ship, but there's a possibility I'll have to do it in a software update later on.

Actually I just had a few minutes free so I added this.

You won't be able to specify software SPI via the BOARD.py file, but you can do it in JavaScript:

var spi = new SPI();
spi.setup({mosi:C7,miso:C8,sck:C9});
E.connectSDCard(spi,C6);
console.log(require("fs").readdirSync())­;

Oh cool!

I'll try this out tonight. I've had a board made since the kickstarter was still running to try this out when it came.

Oh wow, that totally works. Quick test on a random sd card I have.

>var spi = new SPI();
={  }
>spi.setup({mosi:D2,miso:C8,sck:C12});
=undefined
>E.connectSDCard(spi,C11);
=undefined
>console.log(require("fs").readdirSync()­);
[
  "debug",
  "dtbs",
  "MLO",
  "u-boot.img",
  "zImage",
  "initrd.img",
  "uEnv.txt",
  "ID.txt",
  "SOC.sh",
  "flash-eMMC.txt",
  "App",
  "Drivers",
  "Docs",
  "scripts",
  "autorun.inf",
  "LICENSE.txt",
  "README.htm",
  "README.md",
  "START.htm",
  "uInitrd"
 ]
=undefined
Uncaught SyntaxError: Got ?[173] expected EOF
 at line 1 col 41
console.log(require("fs").readdirSync())­;


>console.log(require("fs").readFile("aut­orun.inf"));
[Autorun]
shellexecute=START.htm
icon=Docs\beagle.ico
label=BeagleBone Getting Started
action=Open BeagleBone Getting Started Guide
[DeviceInstall]
DriverPath=Drivers\Windows\FTDI
DriverPath=Drivers\Windows\RNDIS
=undefined
> 

Not sure if that Syntaxerror is anything of note, but it does work. Just built it for the 32F4DISCOVERY since my other board isn't on hand.

  'SD' :  { 'pin_cs' :  'C11',
            'pin_di' :  'D2',
            'pin_do' :  'C8',
            'pin_clk' :  'C12' },

It didn't like the USE_FILESYSTEM define without at least having the pins declared in the board.py

That's great though. I'm sure it'll help a lot of people out.

We're still bound and determined to get the SDIO library working. We have it at least compiling for the Discovery, whether it actually works I dunno yet, going to try that out next.

CKnight and I banged on this a bit more yesterday, and merged in a fork of the STM32F4 (F2) SDIO code using DMA, 4-bit @ 24 MHz, and supporting cards >2GB. This seemed to be working on the STM32F4-DIS-BB platform. We need to review the card swapping, and initialization, but it looked reasonably solid.

The F1 SDIO code needs some work/review, it looks to use ST's code with a 32-bit byte addressing limitation, ie sub 4GB and realistically 2GB, as bigger cards are almost exclusively SDHC.

I uploaded the fork to our repository for review/use. Right now it's set to use the TerminusT2 hardware in the makefile, but a swap to the discovery the hardware will be correct. I also made some slight adjustments in the clock usage. Now you can define the clock in the makefile, just set the divider so that it matches (8Mhz w/ 8, 16Mhz w/ 16).

https://github.com/JanusRC/T2-Terminus/t­ree/master/espruinoT2

The main adjustments that pertain to the SD card are:

ifdef USE_FILESYSTEM_SDIO
DEFINES += -DUSE_FILESYSTEM_SDIO
ifeq ($(FAMILY), STM32F4)
SOURCES += \
libs/filesystem/fat_sd/stm32f2_4_diskio.­c \
libs/filesystem/fat_sd/stm32f2_4_sdio_sd­.c
else
SOURCES += \
libs/filesystem/fat_sd/sdio_diskio.c \
libs/filesystem/fat_sd/sdio_sdcard.c
endif 
else 
SOURCES += \
libs/filesystem/fat_sd/spi_diskio.c
endif 
endif #!LINUX
endif 

And in the board.py file:

'SD' : { 'pin_cmd' : 'D2',
'pin_d0' : 'C8',
'pin_d1' : 'C9',
'pin_d2' : 'C10',
'pin_d3' : 'C11',
'pin_clk' : 'C12' },

If you want to use the bitbanged SPI, you'd have to remove the SDIO defines.

File additions that get called:
-stm32f2_4_diskio.c
-stm32f2_4_sdio_sd.c
-stm32f2_4_sdio_sd.h

As Clive1 mentioned, it'll work correctly if you boot the device up and initialize the library with the SD card in place. If you remove it and re-insert then it breaks, for now anyway.

Sorry, looks like the forum has messed up your Makefile snippet, but thanks for including the repo link.

I'll have to pull that in when I get a second - it'd be nice to rename the existing sdio stuff to f1_sdio as well.

As Clive1 mentioned, it'll work correctly if you boot the device up and initialize the library with the SD card in place. If you remove it and re-insert then it breaks, for now anyway.

I think that happens on all cards unfortunately. It's a side-effect of not having any code to deal with the 'card detect' switch - but most people ignore that anyway.

There's E.unmountSD (I think) which you can call when you're done with the filesystem - which should make it safe to pull the card out.