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.

[Tesla DeLorean]

Posted on November 03, 2017 at 20:34

I'd assume the problem is the layer below FatFs

[Zaher]

Posted on November 03, 2017 at 20:38

Do you mean SDIO? If so, why this happened after the update?

[Tesla DeLorean]

Posted on November 03, 2017 at 20:57

The block device (SDIO, SPI, or whatever) needs to work properly. FatFs will pass through media and subsystem errors to you, and is likely to be vulnerable to being passed junk data and acting upon it.

Before you blame FatFs you need to prove/validate the block storage layer. If that is broken no amount of hand waving at the application level is going to fix it.

If you have Hard Faults, debug them, they are gross errors, and the CPU provides a wealth of detail about why it doesn't like something. Make sure your stack is big enough for the code you are running.

[Lluis Martinez]

Posted on November 09, 2017 at 12:56

I fear the same problem with a

STM32F429

[Marco1]

Posted on November 09, 2017 at 13:29

Now work from my side....but someone must fix this bugs

[Marina Dioto]

Posted on November 13, 2017 at 17:57

I am facing the exactly same problem! Any expectation from ST to fix it? I wanted to know if I should do as Zaher and go back to 4.17 version..

[Tesla DeLorean]

Posted on November 13, 2017 at 18:19

I would expected it to be addressed in future releases, but it should stand as an object lesson in being dependent on software provided by third parties, and the rigor of the testing regime.

Is there anything compelling in the current release that 4.17 wouldn't service adequately?

[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.

[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);

}