FatFs f_open() fails after upgrading to STM32F4 FW pkg 1.17

[Zaher]

Posted on November 03, 2017 at 19:53

I have two versions of my project exported from the CubeMX, one for the MDK-ARM and the other for the gcc-based Eclipse IDE (AC6). Both projects built with STM32F4 firmware package 1.1.

After upgrading the firmware package to the latest 1.17, generating project files again for the MDK-ARM project, my FatFs is no longer able to open files on medium, (SD card). Everything else is working properly, f_mount() returns without error, until the program calls f_open(), which causes Hard Fault and sometimes returns error 3 (FR_NOT_READY).

I tested the same code in the project I have generated earlier for AC6, everything works flawlessly and the file opened without any problem. Generating the project files with the upgraded FW pkg for AC6 has resulted in the same issue in the other project, too, and again, f_open() is no longer works and the program crash with hard fault.

Initially, I thought it's something related to FreeRTOS, as I have been playing around that option back and forth.

I was wondering if this is a known issue in the 1.17 version of the firmware package, as the release notes mention the following:

• Update to use FatFS R0.12c ST modified 201707

Could it be a problem with this new version of FatFs adopted in the FW package 1.17?

I'm going to downgrade to 1.1 and rebuild the project and see if that solves the issue.

Thanks,

Zaher

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Marina Dioto]

Posted on November 13, 2017 at 18:27

I don´t know yet if 4.17 would bring another bug.. I´m hoping not. At the moment I am downloading the zip you sent and I was planning to test it.

[Marina Dioto]

175160CGIL3

[Zaher]

Posted on November 13, 2017 at 18:58

Well, I went through all of that. As far as the solution is concerned, switching back to version 4.17 + FW pckg 1.13.1 was the most viable one for me. I'm doing just fine with 4.17 CubeMx and the aforementioned package. 

[Marina Dioto]

Posted on November 13, 2017 at 19:04

What did you do to switch your project to FW pckg 1.13.1? The most recent library for F4 installed on Cube now is 1.13.0.. I thoght I had to open the ioc project on Cube for it to change back versions, but I cannot open it. Do I need to do something before?

[Zaher]

Posted on November 13, 2017 at 19:14

Well, fortunately enough, I had a backup of my project generated with CubeMx 4.17 and based on the firmware package 1.13.1. I had to re-export the project files somewhere else in my workspace then later manually add all the necessary sources I've been working on before I got interrupted because of that issue (after the update). 

For the STM32CubeMx, you need to remove it completely and install the 4.17 vesion. Just make sure you remove all files and folders for the software before you begin installing that version. By the way, your workspace won't be touched! 

[Tesla DeLorean]

Posted on November 13, 2017 at 19:58

Make a backup of the .IOC, and then manually edit it with a text editor, or Notepad?

[Amel NASRI]

Posted on December 07, 2017 at 10:02

Hello,

For users facing similar issue, please refer to 

https://community.st.com/0D50X00009bMM8bSAG

 

-Amel

[B.Montanari]

Posted on February 26, 2018 at 17:36

Hi!

I had a similar issue recently with the most updated versions so far Cube 4.24.0 and F4 HAL driver 1.19.0

The Cube was configured to use FATFS with SD Card and the SDIO with 4bits interface was chosen, no DMA was configured. In the sd_diskio.c file, automatically created, the code assumes that the DMA will be used (function called is BSP_SD_ReadBlocks_DMA) and there is no #ifdef to change it. So, the f_open wouldn't work due to the SD_read and SD_write function error. The solution was quite simple once identified:

Read:

And SD_write:

with only these changes, it all worked properly:

The code was tested using the Nucleo F401 and the full project is available

https://drive.google.com/open?id=1X9N9ob7u3TxycgdhRcjCDtWx8Qj-02h_

; 

Sure I could add a #ifdef to get a better code format, but this was just a quick fix.

Hope this can help 

Best Regards

[Tesla DeLorean]

Posted on February 26, 2018 at 18:29

DMA and the existing code examples should work properly if the interrupts, and thus call-backs work properly.

Check that the interrupt handlers in stm32f4xx_it.c are properly named

CubeMX seems to be making a dogs breakfast out of the process, and ST needs to get this resolved.

[Tesla DeLorean]

Posted on February 26, 2018 at 19:14

BSP specific DMA code

/* DMA definitions for SD DMA transfer */

♯ define __DMAx_TxRx_CLK_ENABLE            __HAL_RCC_DMA2_CLK_ENABLE ♯ define SD_DMAx_Tx_CHANNEL                DMA_CHANNEL_4 ♯ define SD_DMAx_Rx_CHANNEL                DMA_CHANNEL_4 ♯ define SD_DMAx_Tx_STREAM                 DMA2_Stream6 ♯ define SD_DMAx_Rx_STREAM                 DMA2_Stream3 ♯ define SD_DMAx_Tx_IRQn                   DMA2_Stream6_IRQn ♯ define SD_DMAx_Rx_IRQn                   DMA2_Stream3_IRQn ♯ define BSP_SD_IRQHandler                 SDIO_IRQHandler ♯ define BSP_SD_DMA_Tx_IRQHandler          DMA2_Stream6_IRQHandler ♯ define BSP_SD_DMA_Rx_IRQHandler          DMA2_Stream3_IRQHandler ♯ define SD_DetectIRQHandler()             HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_8)

...

extern SD_HandleTypeDef hsd;

/**

  * @brief  This function handles DMA2 Stream 3 interrupt request.  * @param  None  * @retval None  */void BSP_SD_DMA_Rx_IRQHandler(void){  HAL_DMA_IRQHandler(hsd.hdmarx);}

/**

  * @brief  This function handles DMA2 Stream 6 interrupt request.  * @param  None  * @retval None  */void BSP_SD_DMA_Tx_IRQHandler(void){  HAL_DMA_IRQHandler(hsd.hdmatx);}

/**

  * @brief  This function handles SDIO interrupt request.  * @param  None  * @retval None  */void BSP_SD_IRQHandler(void){  HAL_SD_IRQHandler(&hsd);}