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.

[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

[Tesla DeLorean]

Posted on November 09, 2017 at 14:17

Looks to be expecting a table mapping functions to different subsystems on a drive by drive basis. You need to check the pdrv index and the correct initialization of the object-oriented table. Some assert()s here my help catch this, but you'd ultimately need to work back to where this stuff is supposed to be set up, perhaps a global/static definition.

[Tesla DeLorean]

Posted on November 09, 2017 at 14:26

>>

I was wondering if someone knows where I can get an earlier version of the STM32CubeMx. 

I've got a collection of releases mirrored, any particular version you were looking for?

https://drive.google.com/open?id=0B7OY5pub_GfIdUxPaDl0ZFV3Q1k

 

We tend to put libraries and documentation into the source code management system so we can get contemporaneous information when we have to review failures.

As a note I ported FatFs R0.13 into several of my projects earlier this year to provide EXFAT support, prior to that I'd been using R0.09 for many years.

[Zaher]

Posted on November 09, 2017 at 14:38

Well, to me it looks to be a serious issue in this version of the FW package and I believe someone from ST has to take a look and fix it. For now, I prefer to go back to the last working library package and spend time on other aspects of my projects rather than troubleshooting this one. The problem is, the updated version of STM32CubeMx doesn't generate code and configurations compatible with older FW packages. 

Any advice?

[Zaher]

Posted on November 09, 2017 at 14:40

Well, the MCU has nothing to do with it. It's just a problem with the library. On top of which version you are building your project?

[Zaher]

Posted on November 09, 2017 at 15:03

I've got a collection of releases mirrored, any particular version you were looking for?

Thank you very much Mr. Clive. Well, I do not recall precisely on which version I was building the project before the update, but it has to be around 4. I will try to install that version then re-download the 1.1 FW package.

[Zaher]

Posted on November 09, 2017 at 22:15

Got it now. I just found a backup of a project created earlier for AC6 and the code was generated with CubeMx 4.0. Do you have it among your collection?

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