FATFS f_opendir function does not work after updating to CubeIDE 1.7.

[DAbi .1]

I have a working firmware that reads from a SD card on a STM32L476RG using CubeIDE 1.6.1.

In the past I have downloaded CubeIDE updates and after migrating the project to the new version the firmware still works fine, until I updated cubeIDE from version 1.6.1 to version 1.7. After migrating the project to cubeIDE 1.7 the function f_opendir returns a error number 1 (other FATFS functions like reading or writing to a file or creating a directory works fine). In addition, the MCU hangs up when trying to read the MCU temperature and an additional Analog input that I programmed for reading voltage. Fortunately I did a backup of the working folder so I can go back to the previous version, but I was wondering if this is a bug or if there is something else I'm missing. I compared the main.c builds between two versions and I see only differences in some of the clock configurations (not related to the SD Card) but the rest looks the same. Thanks.

[Walid ZRELLI]

Hello @DAbi .1​ ,

This issue has been internally raised. I will keep you posted.

Thanks for your contribution.

BeST Regards,

Walid

[Walid ZRELLI]

Internal ticket number: 114180 (PS: This is an internal tracking number and is not accessible or usable by customers)

[mattias norlander]

Hi,

Were you able to resolve the issue?

The symptoms you describe sounds quite random. My first thought is whether there could be an issue related to thread-safety / re-entrance.

If you have a multi-threaded application, and different threads makes to C library functions like malloc, printf, strtok, ... Then you have to make sure that these C library functions calls are safe to make. malloc as an example contains a critical section. If an IRQ were to fire while you execute malloc AND the ISR also makes a call to malloc, there is a chance that both malloc calls will point to the same memory address. This will likely lead to memory corruption sooner or later --> random crashes...

• Is this a bare-metal application or do you use an RTOS?
  • If bare-metal applications, are you making any calls from ISR context to C library functions?
  • If RTOS-application, are you making any calls to C library functions from (thread or ISR context?

There is a thread-safe solution provided with CubeIDE/MX which will lock a subset of the C library functions and thereby protect your application against this type of issues. Re-entrant related issues are however still a headache that you need to be careful with. For example parallel calls to strtok and management of reent structs.

The thread-safe solution is described in CubeIDE User Guide. In case of CubeIDE 1.7.0, look at chapter 2.7: Thread-safe wizard for empty projects and CDT™ projects

[DAbi .1]

Thank you for your detailed answer. Indeed the problem might be related to what yo mentioned. I was able to solve the issue with the ADC read by following the ADC example in the repository which uses low level methods mixed with HAL methods. I yet haven't tried solving the f_opendir issue since I'm still using the CubeIDE 1.6.1 version. My application does not use RTOS and I do use strok. Unless you close the tread, I'll provide a follow up answer if a find the problem causing the f_opendir issue.

[mattias norlander]

Thanks - could be interesting for other community members. Keep us updated!

[mattias norlander]

Some further pointers, that may help you troubleshoot and feel more confident about the issue:

• If the problem is related to malloc or similar C library function which contains a critical section, but does not require multiple sets of global data, then the thread-safe solution should help.
  • In your case, since you are not relying on and RTOS, assuming your hardware allow this, I would try "strategy#3" (in the thread-safe solution). This means that a malloc() or similar C library function call from ISR context will get trapped in the Error_Handler() when malloc() tries to acquire a lock. Careful though, consider any H/W implications by halting execution in ISR...!
• If the problem is related to strtok() or any other C library function which has reentrant version and which may manage multiple sets of global data. Then the thread-safe solution will not help you. Instead scan your project calls to the non-reentrant version of such function and make sure you manage reent structs properly. Use strtok_r() instead whenever applicable and manage the _impure_ptr.

Have a look here as a source of inspiration: https://sourceware.org/newlib/libc.html#Reentrancy