STM32F407-DISCOVERY SDIO tests.

  • 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 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 useSDIO_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
0000080

Looks less random to me.

  • 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 like this. Program hangs after returning from interrupt routine(?) In fact I don’t really know what is happening… Program hangs inSD_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)) {
    timeout--;
}

Normally after successful transfer either DMAEndOfTransfer or TransferEnd would turn 1, but seemingly none of this happened. The only place the TransferEnd is set isSDIO_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.

4 comments for “STM32F407-DISCOVERY SDIO tests.

  1. February 6, 2014 at 12:26 am

    Thanks so much for this! I spent days trying to get ST’s sample code working and banging my head against the wall. I compiled your code and am having more success.

    Question: do you have any idea why line 1356 of sdio_high_level.c sends me to HardFaultHandler? The line is:

    logf (“2 DMAEndOfTransfer = %d, TransferEnd = %d, TransferError = %d, timeout = %d\r\n”, DMAEndOfTransfer, TransferEnd, TransferError, timeout);

    I suspect it may be that I’ve set up my build environment incorrectly, but I’m afraid I have no clue what I did wrong. Any ideas for me?

    • admin
      February 6, 2014 at 8:34 am

      Hi.

      logf is nothing special, it is a simple #define for printf which I can turn on and off at will. So I would comment that line, and check if program hangs somewhere else (on the next “logf” maybe?). If so, I would turn off logging (logging.h If I remember, define logf as empty macro or something like that, I’m at work right now, and don’t see the code). If the issue is caused by logging (by printf) and you want to see the logs I would check the syscalls.c file. Maybe try to change USART port number (STDOUT_USART etc), or check out the function called _write – maybe it can be improved. On what eval-board you are working? STM32F407-DISCO? Good luck!

  2. jules
    May 9, 2014 at 1:46 am

    Hi
    i really appreciat your work on STM32F4DISCOVERY am i will need your help please it’s urgent.
    I have build a FTP server base on STM32discovery and a FREERTOS
    I have try with µCOS-III TCPIP and FreeRTOS+Lwip (the http_server_socket example) any time the client (base on java) will connect to the server but when the server will try to send a message to the client it will not go and i will have a Hardware fault the ping to the server works very well.
    and working with IAR.
    please i will be happy if you can help me or allow me to get in contact with ou

    • admin
      May 9, 2014 at 3:32 pm

      Hi. Unfortunately I have no experience in any RTOS and TCP/IP stack for STM32 whatsoever. This is slightly more advanced and high-level stuff you are dealing with, so maybe try on my.st.com or something? Good luck.

Leave a Reply

Your email address will not be published. Required fields are marked *