NUCLEO-H743ZI2 SDIO interface, how to utilize SDR104 data rate?

[27troadster]

I am using a NUCLEO-H743ZI2 to read 16-bit data in via GPIO pins and store that data to an SD Card. I would like to achieve an average write speed of 20 Mb/sec for data sets up to 10 Gbytes. I am using 4-bit wide bus and have wired an SD card holder to the SDMMC pins.

It transfers works, but it's slow because it cannot utilize the UHS-1 speeds.

After pouring through RM0433, every Application Note from STM, youtube tutorials, SD Specification sheets from SD Association and the internet, I'm still stuck and have the following questions:

Questions:

1) Does the NUCLEO-H743ZI2 have a voltage transceiver to shift to 1.8V? It doesn't appear to, but I can't find a definitive answer.

2) Assuming the board does not have a transceiver, is there a break out board with a transceiver that you would recommend?

3) The RM0433 Reference manual, page 2453, states "The signal voltage level is supported through an external voltage translation transceiver i.e. ST6G3244ME." But the data sheet for this IC (located at: https://datasheetspdf.com/pdf-file/711395/STMicroelectronics/ST6G3244ME/1) states that it "Supports 60 MHz clock rate." Does that mean using this chip we cannot reach the 104Mhz for SDR104?

4) Also, is the only package for the ST6G3244ME BGA? Are there any break out boards for the ST6G3244ME?

And finally, am I going down the completely wrong path? In other words, is there a better way to store 20 Mb/sec average data rate for up to 10 Gbytes? ie: eMMC, external RAM, USB to PC, USB to a High speed SD Card reader, Gbyte Ethernet, etc?

Thank you for any help you can give on this topic.

Kipp

[Tesla DeLorean]

The NUCLEO board does not have a transceiver, see schematic. The EVAL (H743) has a transceiver, but the NXP module is obsolete.

20 Mb or 20 MB/sec

The interface is probably capable of running quite fast, the real issue would the wiring and transmission line issues hanging off the NUCLEO. Should be able to demo 50 MHz

eMMC would have the advantage of 8-bit, and not requiring 1.8V operation for DDR.

The STM32 SDMMC/FATFS aren't particularly optimized for high speed operation, no real OS, or caching. I think it would take some significant effort to get streaming writes at high sustained speeds.

[27troadster]

Tesla,

Thank you for the reply and the confirmation for the NUCLEO board.

20 Mb or 20 MB/sec: 20 MB/sec (Megabytes per second)

"the real issue would the wiring and transmission line..." Agree, not sure how to improve this, some ~10nF caps near the SD Card on data lines, clk, and cmd?

"eMMC..." - I assume you are referring to an MMC card correct? I've not had any experience with these, looks like I will have to do some reading and get smart on them. Do they use the same SDMMC registers as the SD card? I assume they do, just different commands and responses sent between host and card, right?

"The STM32 SDMMC/FATFS aren't..." - I avoided that problem in two different ways, both worked:

1) Keep the FATFS but write blocks directly to SDMMC1 registers: I use the STM32 SDMMC/FATFS to initialize the SD card, mount the SD card, open a file then at the point the low level HAL drivers are about to send the "write a block to the SD Card" command (command index 24) in SDMMC1 registers, I split off to my own code written in ASM, ran from ITCM, which reads GPIO pins, buffers the data in AXI SRAM, then directs SDMMC block transfer when 512 bytes are in the buffer. I haven't rounded it out yet by closing the file and updating the length in the FAT table. But it does work and allows use of FATFS. Then the SD card can be read by any computer.

2) Get rid of any file system on the SD card and just write bytes to it like it was any other memory space: I use the CubeIDE to set up SDMMC1 but I don't enable a FATFS from "middleware." The CubeIDE Generated code will then initialize the SD Card. I then tell the SD Card to go to 4-bit wide data using Hal library. Then write to the card using SDMMC1 registers directly from ASM code that is loaded into and ran from ITCM same as above.

Thanks,

Kipp

[Tesla DeLorean]

eMMC is the chip level equivalent to an SD/MMC card, but also having an 8-bit mode, a bit like MMC-PLUS but without the hassle of finding cards/sockets. Same peripheral, and mostly the same driver/commands. On SanDisk/Samsung you can tell the eMMC how much data is coming, so it doesn't have to second guess the what's happening next aspect of this data access. If you don't like BGA's probably not for you, but several Linux SBC have adapters so you can pin/socket them, and so does Nintendo. They have an DDR mode, not sure it actually increases the throughput.

Signal integrity, problem here is that it's bi-direction, and ringing because it's not terminated. Generally some 22, 27 or 33 R series resistors on the signal/clock lines helps, as does backing off the slew-rate on the STM32 side (SPEEDR) as the traces are generally quite short, and the drivers overly aggressive. Pull-ups on the data/cmd line at the socket, 47K

Transceiver, if you don't like the BGA/MCM approaches, I'd hazard this could be done with off-the-shelf SMT IC using modern 74 series equivalents (bi-directional buffer, with direction pin, and different voltages on each side). I think the auto-sensing buffers would be a disaster, but I'd be amused if someone tried and got them working.

My biggest concern with 20 MB/s would not be doing that, but the "whilst doing something else" that inevitably comes with it.