search

STMicroelectronics / STM32CubeL4

STM32Cube MCU Full Package for the STM32L4 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))
Other
262 stars 153 forks source link

Fix SD_DMATransmitCplt #35

Closed smartel99 closed 3 years ago

smartel99 commented 3 years ago

Fixed SD_DMATransmitCplt to actually do what it's supposed to do. It now properly checks the status of the transfer, clears the interrupt/request flags and call the SD DMA transfer complete callback function.

RKOUSTM commented 3 years ago

Hi @smartel99,

First of all, we would like to thank you for your contribution. Thank you also for the interest you are showing to our firmware.

Your request will be forwarded to our development team. We will get back to you as soon as we have more details.

With regards,

RKOUSTM commented 3 years ago

Hi @smartel99,

Thank you for your contribution. I discussed further your proposed fix with our development teams and they needed same clarification. So, in order to allow a better analysis of the suggested fix and to integrate it in our future releases, could you please give us more details about the problem that lead to this pull-request .

Thank you again for your contribution.

With regards,

RKOUSTM commented 3 years ago

Hi @smartel99,

Any new comments to move this discussion forward?

With regards,

smartel99 commented 3 years ago

The problem, as it can be found by reading the many, many posts on this very topic online, including on ST's own forum, is that the SDMMC driver does not work with fatfs.

The issue is occurring when trying to write anything to the SD card through fatfs. I haven't tried directly using the HAL SDMMC drivers to accomplish that write, but I suspect it suffers from the same problems...

This occurs no matter the configuration: Polling/DMA, 1-bit wide/4-bit wide buses, 240kHz/1MHz, 5MHz, 16MHz, 20MHz, 32MHz clock speed, etc.

I have traced the path taken by the code during a write sequence, and once it reaches SD_DMATransmitCplt, it just stops there, which means that it blocks further down the line in the fatfs code. Looking at the SD_DMAReceiveCplt function, they clearly do significantly different operations, way more different than what I would expect to be different between these two callbacks.

This is an issue that dates from over 5 years ago on multiple (possibly all) packages of the CubeMX, it is not a problem exclusive to the STM32L4 package.

My apologies if I am salty, but seeing that this 5 years old issue has not been fixed by a corporation with a 10 billion euro revenue pisses me off, especially now that I read that the team in charge doesn't see the really obvious problem. Searching for "stm32 fatfs sd card unable to write" on Google gives over 36 000 results, and adding "community.st.com" to the query leaves 30 000 results. 30 thousands results. STMicro is not a tiny company run by a few people, it's an international corporation that stands on the same level to other giants like TI, NXP and Microchip. I except a lot more than this from STMicro.

Having found a solution that works for my case, which is to not use ST's SDMMC driver but instead the SPI driver interfaced with fatfs through a third-party library, I have no further intention to troubleshoot/fix this issue, but, since STMicro seems to be unable to solve this issue, I hope that this information will be enough to prevent anyone from going through the weeks-long troubleshooting process I had to go through to realize that the most up-to-date version of a first-party library provided by STMicro themselves does not work.

smartel99 commented 3 years ago

Reading files through fatfs works flawlessly, it is really just when trying to write that it hangs in the SD_Write function in FATFS/Target/sd_diskio.c, a file generated by STM32CubeMX.

It hangs while waiting for WriteStatus to equal 1, which never happens because BSP_SD_WriteCpltCallback is never called.

RKOUSTM commented 3 years ago

Hi @smartel99,

Thank you for your contribution. The point you reported is related to the CubeMX generation problem and not directly related to the firmware published in this repository. Unfortunately we don't treat aspect related to CubeMX tool in our GitHub repositories.

In order to speed up the analysis procedure, this point has ben reported to CubeMX development teams who will take in charge the issue. It will be fixed and made available in a future STM32CubeMX release.

Now, as this issue is not directly related to some software component published within this repository (CMSIS, HAL, BSP, etc.) but rather to our ecosystem (namely the CubeMX tool), please allow me to close it.

Thank you for your comprehension and thank you for your contribution. We are looking forward to reading from you again.

With regards,