f_write bug - report

con3 · ‎2017-12-01

Posted on December 02, 2017 at 02:05

The original post was too long to process during our migration. Please click on the attachment to read the original post.

Amel NASRI · ‎2017-12-06

Posted on December 06, 2017 at 16:13

Hi @piet_t,

Thanks for sharing your findings.

I'll sharethem internally for farther checks as I think that HAL_SD_WriteBlocks_IT is correct: the SD card state is set to 'HAL_SD_STATE_READY' in the HAL_SD_IRQHandler.

Don't you agree?

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

con3 · ‎2017-12-06

Posted on December 06, 2017 at 17:58

Hi Amel,

I'll need to check. I didn't directly debug the IT functions as the HAL_SD_WriteBlocks_DMA was an issue for me. I just noticed that the HAL_SD_STATE_READY' didn't appear to be set in the IT functions either at a quick glance. I know that the HAL_SD_WriteBlocks_DMA and DMA read definitely don't have their states changed back to 'HAL_SD_STATE_READY' as running the function multiple times it had failures due to the state being busy even though the function returned OK. adding the above mentioned code solved all the issues and the system was able to mount, open and write.

-Piet

Andrew Sund · ‎2017-12-28

Posted on December 28, 2017 at 18:45

Maybe this is not the case as I am looking at the L1 libraries, but it looks like you are supposed to call HAL_SD_CheckWriteOperation or HAL_SD_CheckReadOperation that implements a spinloop on the transfer completion and then resets the flags. Kind of dumb for a DMA driver to spin like that, but there you have it.

You might be able to hook into one of the transfer complete callback functions (Looks like HAL_SD_DMA_RxErrorCallback or HAL_SD_DMA_TxCpltCallback?) to call these functions with no polling penalty (the transfer will be guaranteed to be done) and send an RTOS semaphore that your user code is blocking on instead of calling the polling functions.