• Started a new project (includes StdPeriph 1.3.0). Repository can be found  here.
  • First commit makes it simply output a “Init” text on the debug console (i.e. on USART1).
  • Browsing StdPeriph. Seems that stm32f4xx_sdio.[ch] are very low level (I’ve read SD card spec version 2.0).
  • Higher level stuff seems to be in StdPeriph here:
  • Utilities/STM32_EVAL/STM324x7I_EVAL
  • Utilities/STM32_EVAL/STM3240_41_G_EVAL
  • Utilities/STM32_EVAL/STM324x9I_EVAL

But I don’t know why there is one version per dev-board. Looks like bad design to me at a first glance. Differences between those 3 files:

  • Lines 517/519 : Card presence is detected by different means (different pins are used on these boards). As far as I remember card presence detection is an optional feature, so maybe even it is not part of the standard. That would explain why different pins are used on the boards (I expect, that standard pins are laid out the same on …?).
  • Lines 1570/1572 different parameter passed to  SDIO_ITConfig in function  SD_WriteMultiBlocks. One dev-board uses  SDIO_IT_RXOVERR and the other two use SDIO_IT_TXUNDERR (among others, this is a bitmask).
  • Copied STM324x9I_EVAL sdio routines to my source tree.
  • Included code from the SDIO example :  Project/STM32F4xx_StdPeriph_Examples/SDIO/SDIO_uSDCard. Serial console went crazy and shows some gibberish, so I can’t see my debug messages, but card previously filled with random data now shows :
root@diora:~# hexdump -n 128 /dev/sdc 
0000000 0100 0302 0504 0706 0908 0b0a 0d0c 0f0e
0000010 1110 1312 1514 1716 1918 1b1a 1d1c 1f1e
0000020 2120 2322 2524 2726 2928 2b2a 2d2c 2f2e
0000030 3130 3332 3534 3736 3938 3b3a 3d3c 3f3e
0000040 4140 4342 4544 4746 4948 4b4a 4d4c 4f4e
0000050 5150 5352 5554 5756 5958 5b5a 5d5c 5f5e
0000060 6160 6362 6564 6766 6968 6b6a 6d6c 6f6e
0000070 7170 7372 7574 7776 7978 7b7a 7d7c 7f7e

Looks less random to me.

  • I had problems with serial console attached to USART1 after upgrading StdPeriph from 1.1.0 to 1.3.0. Console would speak Chinese from now on, and logic analyzer shows “framing errors” when attached to the TX pin. There were two problems: in 1.1.0 in file  stm32f4xx.h default  HSE_VALUE definition was 8MHz. In 1.3.0 ST increased this to 25MHz. In addition in  stm32f4xx_conf.h I had HSE_VALUE redefined, but later on I upgraded this file (got it from some example projest from StdPeriph from 1.3.0 version), and it lacked this re-definition. Thus µC thought it is running on 25MHz which in turn disrupted the transmission. This re-definition looks as follows:
#if defined  (HSE_VALUE)
/* Redefine the HSE value; it's equal to 8 MHz on the STM32F4-DISCOVERY Kit */
 #undef HSE_VALUE
 #define HSE_VALUE    ((uint32_t)8000000) 
#endif /* HSE_VALUE */
  • I am facing a  similar problem to this. Program hangs after returning from interrupt routine(?) In fact I don’t really know what is happening… Program hangs in SD_WaitReadOperation after successfully returning from  SD_ReadMultiBlocks. It idles in loop (or at first glance it looks like it is iterating the loop forever) which looks like this:
while ((DMAEndOfTransfer == 0x00) && (TransferEnd == 0) && (TransferError == SD_OK) && (timeout > 0)) {

Normally after successful transfer either DMAEndOfTransfer or  TransferEnd would turn 1, but seemingly none of this happened. The only place the TransferEnd is set is SDIO_IRQHandler, so I added logs to check if µC hits this routine. It does, and it even set  TransferEnd to 1, but it never returns from it. Debugger says, that program hangs in some strange places like WWDG_IRQHandler.

The problem was caused by missing DMA handler routine, namely the  DMA2_Stream3_IRQHandler. I made two mistakes. First, I assumed, that since I run the demo with SD_DMA_MODE turned off (undefined), and SD_POLLING_MODE turned on (#defined), the DMA routines are unnecessary. This is not the case, those handlers are required in either cases (that’s the way SDIO example is made). So I copied DMA_IRQ handler from the example, where its name was hidden behind the SD_SDIO_DMA_IRQHANDLER macro (but at that point I didn’t know this is a macro, and thought that this is a regular function name). So secondly, SD_SDIO_DMA_IRQHANDLER was undefined in my stm32fxxx_it.c, It simply was not visible in this translation unit, and I ended up with function named SD_SDIO_DMA_IRQHANDLER, but without proper DMA IRQ handler. So µC jumped to the default handler which had infinite loop in it, but for some reason GDB showed the other handler.