2016-11-30 09:41 AM
Hi,
I am using fatfs sdio with my stm32f429 mcu. When i use f_open function in main loop it works well, but when i use it in timer interrupt callback function it fails, it does not return from fatfs. what can the relationship be between timer interrupt and fatfs? Any advise??2016-11-30 09:47 AM
The current forum software (due to be replaced next week) does not support mobile devices, please restate your problem using a desktop browser, or Firefox on mobile.
There are many threads on F4 SDIO + FATFS using the SPL, with example projects, please review if any of those address your situation/issues.2016-12-02 02:34 AM
Hi
eb3484, Try to check and play on the following :- SDIO CLOCK (too fast ?)- heap and stack size (should be increased)- interrupts priority ( there another interrupt with higher priority ?)Although, check the read-to-use example ''FatFs_uSD''
inside the STM32Cube to compare the code with your own ; at this path
STM32Cube_FW_F4_V1.14.0\Projects\STM324x9I_EVAL\Applications\FatFs\FatFs_uSD
-Hannibal-2016-12-05 09:37 AM
The FatFs+SDIO implementation is not thread/interrupt safe, you need to move all action into a single thread, perhaps a foreground task, or find a way to serialize interaction with the driver stack that doesn't create a dead-lock.
I would not try to run any FatFs stuff within an interrupt, one needs to watch the priority/preemption levels of the SDIO and DMA, and for code that blocks.
2016-12-05 09:54 AM
Hello,
I assume that in your example the FatFS is using the SDIO without DMA. In this case the any interrupt will break the SDIO Tx/Rx routine and cause overflow/underflow.
The solution for that is to use the SDIO read and write with DMA. For this the DMA initialization must be added and the interrupt from DMA also.
For the SDIO with DMA i would recommend to look into CubeMX example:
STM32Cube_FW_F4_V1.13.0\Projects\STM324x9I_EVAL\Applications\FatFs\FatFs_uSD
Best regards
Radek
2016-12-05 11:30 AM
I think you're still going to get caught by blocking the IRQ, or callback, you are in, or by a failure to serialize access to the resource(s).
In the data recorders I've worked on, we collect data into buffers rapidly in interrupt handlers, and flush large buffers to the storage media efficiently in a worker thread. Doing small f_write()'s is just going to be brutal to system performance and functionality.