Clive Two.Zero

STM32439I-EVAL2 SDIO Experiments

Blog Post created by Clive Two.Zero on Mar 12, 2018

For reasons that aren't entirely clear Element14 decided to flush current inventory of STM32439I-EVAL2 boards last week, so instead of $500+S/H I picked one up for about $80 landed.

I had actually been searching of an MB1063 (640x480) panel to use on my H743I-EVAL, which I'd picked up with an MB1166 DSI panel, and tested with an MB1046 (480x272) I'd gotten with an earlier F439I-EVAL.


In previous experiments I've had the DSI-HDMI adapter on the F769I-DISCO driving an 640x480 and 800x600 screen, which seems to be about the ceiling for the ADV7533 with 2-lanes, and learned that with very high video bandwidth SDIO/SDMMC writes would fail sooner or later if actually tested or mildly stressed. It turns out that POLLED MODE gets a TX UNDERRUN error even at nominal 25 MHz bus speeds, and more so if you do it on fast cards at higher rates. You have to use DMA, and you need to port most of the examples to use DMA mode because they are using POLLED mode. Not really run into this before because a) most of my stuff in recent years is head-less, and b) my SPL implementation uses DMA, and I have data loggers running for months on end without issues. The same app would die in under and hour on the F769I-DISCO, mainly because I would close a file and open a new one at the top of each hour, and failures earlier finally catch up with FatFs to the point it stops working properly.


Anyway, with a new STM32(F)439I-EVAL2 hand I decided to see how HAL would work. Turns out the MB1063 with a 25.17 MHz pixel clock can be broken in under a minute.


I have RS232 and SWV channels outputting diagnostics, I instrument SD_write() to chirp on failure. This doesn't act as a drag on bench marking, but does permit me to understand when SDIO/FATFS comes off the rails.


DRESULT SD_write(BYTE lun, const BYTE *buff, DWORD sector, UINT count)

    if (res!= RES_OK) printf("W %9d %3d %d (%08X)\n", sector, count, res, uSdHandle.ErrorCode);
  return res;


I then stress FatFs by writing a 650MB file of pseudo-random data, very easy to generate very long, complex, and yet reproducible data patterns which test the integrity of the file system and the media. I don't find writing the same dull 0x00 or 0xFF data pattern to every cluster on the media a helpful way to test things thoroughly, inducing failure quickly and obviously saves a lot of time in these experiments. The key with block storage devices is that they give you back what you put into them.