Why can I not get past f_open with SD card

[GreenGuy]

Posted on March 05, 2018 at 05:51

I am working with STM32F746G-Disco board to prove out the use of the SD card.  I am at a point where I cannot get the code to write data to the card using the fs calls.  First, I have setup the board in CubeMX with all the peripherals for the disco board initialized although I am only working with the FATfs, SD card and the screen for debug. The Cube project file is attached.  The code is working up to the point where f_open is called but f_open does not seem to return.  The code looks like this:

  /* USER CODE BEGIN 5 */

  sdres = BSP_SD_Init();  if (sdres == FR_OK) BSP_LCD_DisplayStringAt(0, 94, (uint8_t *)'SD Init status Pass', LEFT_MODE);  else BSP_LCD_DisplayStringAt(0, 94, (uint8_t *)'SD Init status Fail', LEFT_MODE);

  sdres = f_mount(&sdFatfs, '', 0);

  if (sdres == FR_OK) BSP_LCD_DisplayStringAt(0, 124, (uint8_t *)'SD mount Pass', LEFT_MODE);  else BSP_LCD_DisplayStringAt(0, 124, (uint8_t *)'SD mount Failed', LEFT_MODE);

  sdres = f_open(&sdFile, 'test.txt', FA_OPEN_ALWAYS|FA_WRITE|FA_READ);

  if (sdres == FR_OK) BSP_LCD_DisplayStringAt(0, 124, (uint8_t *)'SD open Pass', LEFT_MODE);  else BSP_LCD_DisplayStringAt(0, 124, (uint8_t *)'SD open Failed', LEFT_MODE);

  sdres = f_lseek(&sdFile, sizeof(&sdFile));

  if (sdres == FR_OK) BSP_LCD_DisplayStringAt(0, 124, (uint8_t *)'SD seek Pass', LEFT_MODE);  else BSP_LCD_DisplayStringAt(0, 124, (uint8_t *)'SD seek Failed', LEFT_MODE);

  sdres = f_printf(&sdFile, '%s', buffSDwr);

  if (sdres == FR_OK) BSP_LCD_DisplayStringAt(0, 124, (uint8_t *)'SD print Pass', LEFT_MODE);  else BSP_LCD_DisplayStringAt(0, 124, (uint8_t *)'SD print Failed', LEFT_MODE);

  sdres = f_close(&sdFile);

  if (sdres == FR_OK) BSP_LCD_DisplayStringAt(0, 124, (uint8_t *)'SD close Pass', LEFT_MODE);  else BSP_LCD_DisplayStringAt(0, 124, (uint8_t *)'SD close Failed', LEFT_MODE);

The sdFile, sdFatfs, sdres, and buff... variables are all global to main.c being declared in the USER PV area.

When this runs, the LCD screen prints

SD Init status Pass

SD mount Pass

after which nothing else appears.  It is also interesting to note that if I set break points at the f_open call and just after the call, the debugger stops at f_open but when I click run to go to the next break point the execution pointer simply stops at the f_open call again.  ODD!  If i place the cursor a couple of lines down and select run to cursor, the same thing happens.  If I try to step over the f_open line the debugger ends up at the first instruction in the tick handler.  I have exhausted all the posts, youtube tutorials, and blogs and nothing has settled the issue.

[GreenGuy]

Posted on March 08, 2018 at 21:58

Well I am not sure what to do with this information.  I can see that the first section:

void BSP_SDMMC_DMA_Tx_IRQHandler(void)

{  HAL_DMA_IRQHandler(uSdHandle.hdmatx);}

is not in stm32f7xx_it.c so I assume you are suggesting that it be added.  The #define preceding the section of code of interest is already defined in stm32f7xx_hal_dma.h so I simply put a #include in the user section of stm32f7xx_it.c.  I compiles but when ran it does not change the behavior which is when f_close is called the function times out for 30 seconds and returns the same FR_DISK_ERR.

[GreenGuy]

Posted on March 08, 2018 at 22:52

Not sure this is necessary (see last post).  The stm32f7xx_it.c already has a global SDMMC1_IRQHandler that is being called as a result of the flush.  I can see this in the debugger as this routine breaks with the stack showing f_close > f_sync > disk_write > SD_write > sync handler called > SDMMC1_IRQHandler.

[GreenGuy]

Posted on March 08, 2018 at 22:56

I am using SW4STM32.

[GreenGuy]

Posted on March 08, 2018 at 23:07

It would be nice if the Cube MX BSP worked for this case.  Interesting to note is the comment in the HAL_DMA_PollForTransfer function which states;

'@note   The polling mode is kept in this version for legacy. it is recommanded to use the IT model instead.

  *         This model could be used for debug purpose.'

Is there any good documentation regarding the callback registration used in stm32f7xx_hal_dma.c?

Looks like this code is an unfinished thought.

[GreenGuy]

Posted on March 08, 2018 at 23:50

Would it be fair to open a ticket on this?  Or do I have to solve a problem with code belonging to someone else before it is recognized as a bug?

[Tesla DeLorean]

Posted on March 08, 2018 at 22:50

Well it was provided as a road-map of how it functions when it works properly through the levels of obfuscation.

The thing with the DMA is that the transfer completes before the transaction closes as it fills a FIFO, ie a leading indicator. The transaction on the bus is managed by the SDMMC which interrupts after all the data has transited. ie a trailing indicator.

Would a working build for the STM32F746G-DISCO, driving the screen and the microSD be helpful?

A good existing polled example is

STM32Cube_FW_F7_V1.9.0\Projects\STM32746G-Discovery\Applications\Display\LTDC_PicturesFromSDCard

I've added in USART and SWV debug output, and merged in working DMA support, using Keil

[Tesla DeLorean]

Posted on March 08, 2018 at 23:22

>>

It would be nice if the Cube MX BSP worked for this case. 

Yes it would, hopefully something is going on in the background, because all I'm hearing is crickets.

[Tesla DeLorean]

Posted on March 09, 2018 at 00:17

My guess would be that there has been enough visibility generated here that it is on someone's radar already.

The SDIO/SDMMC stuff seems to be going through a transition based on the first releases of support for L4+ and H7 parts, so likely some unification and refactoring of things across the families.

[GreenGuy]

Posted on March 09, 2018 at 02:20

Well I need it working so I will take a stab at it.  My best guess at the moment is that the HAL_SD_TxCpltCallback and HAL_SD_RxCpltCallback need to be registered and are not even in the list of callbacks in the callback Registration function.  The best place to register the HAL_SD_TxCpltCallback is at the point just before the code that depends on the WriteStatus semiphore.

[GreenGuy]

Posted on March 09, 2018 at 02:23

If anyone wishes to tackle it ahead of me great.  I am not proud, just needy.

Thanks so far for your help.