SD card DMA callbacks not firing - f_write/f_close return FR_DISK_ERR after 30s timeout

[CyberDuck79]

Hello Electro-smith team !
Here is a problem I have encountered when trying to implement SD card writes on the daisy patch.
I must admit that without an LLM to help me debug I would never found the fix by myself.
The fix is not ideal as polling mode is slightly slower and blocks the CPU during transfers, but for my use case (saving presets), it is sufficient.

Description

When using FatFS with the SDMMC peripheral on Daisy Patch, SD card writes always fail with FR_DISK_ERR (error 1) after a 30-second timeout. The file is created but remains at 0 bytes. Switching to polling mode in sd_diskio.c fixes the issue.

Hardware

• Board: Daisy Patch
• SD Card: FAT32, MBR partition scheme (tested with multiple cards)

Problem

The DMA completion callbacks (BSP_SD_WriteCpltCallback / BSP_SD_ReadCpltCallback) in sd_diskio.c are never called. This causes the while loop in SD_write() to spin until SD_TIMEOUT (30 seconds) expires:

// sd_diskio.c line ~220
while((WriteStatus == 0) && ((HAL_GetTick() - timeout) < SD_TIMEOUT)) {}

WriteStatus stays 0 because BSP_SD_WriteCpltCallback() never fires.

Workaround

Replacing DMA calls with polling versions fixes the issue:

// In SD_read():
// Change: BSP_SD_ReadBlocks_DMA(...)
// To:     BSP_SD_ReadBlocks(..., SD_TIMEOUT)

// In SD_write():
// Change: BSP_SD_WriteBlocks_DMA(...)
// To:     BSP_SD_WriteBlocks(..., SD_TIMEOUT)

Full diff: master...CyberDuck79:libDaisy:fix/sd-polling-mode

Steps to Reproduce

1. Use the official SDMMC example pattern on Daisy Patch
2. Try to write any file with f_write() / f_close()
3. Observe 30-second hang, then FR_DISK_ERR
4. File exists but size = 0

Environment

• libDaisy version: master (latest)
• Toolchain: arm-none-eabi-gcc 14.2.1

Questions

• Is the SDMMC DMA/interrupt configuration correct for Daisy Patch?
• Are there known issues with IDMA on STM32H750?

[CyberDuck79]

Note: There appears to be a similar DMA callback issue with UART (see issue #653). While SDMMC uses IDMA not regular DMA, this may indicate broader DMA/interrupt handling issues in libDaisy.

[TheSlowGrowth]

Please try this PR: #678

It sounds like you're running into the same issue.
The ReadStatus and WriteStatus variables which are part of the loop were not declared as volatile. Hence the compiler doesn't realize that they can change, and optimizes them away, leaving only the timeout in the while statement.

There's even a comment in line 59 that suggests that the volatile keyword was there at some point...

The PR with the fix has been sitting 3 months. God knows if they merge it eventually.

[CyberDuck79]

Oh cool! It is 11 PM here in France, so I will try that tomorrow.

[stephenhensley]

The PR mentioned above has been merged. So you should be good to try on the master branch as well.

@CyberDuck79 if you're still running into issues after trying this update, please re-open the issue, but I think it should be resolved. 😄

[CyberDuck79]

Sadly, it does not work. I tried with the current master branch, checked that volatile was here, cleaned, and recompiled libdaisy, but I still get FR_DISK_ERR (1) after 30 seconds.

[CyberDuck79]

@stephenhensley I can't re-open the issue.

[stephenhensley]

@CyberDuck79 hmmm, good to know.

Are all of the objects you're using to communicate with the SDMMC located in the AXI SRAM or the SDRAM memory section?
The STM32 is limited in which memory sections have access to the SDMMC1 peripheral that we use.

I believe this would be any of the FatFS data types (FIL, etc.) and actual buffers that you're reading/writing with.

That said, I wouldn't expect the polling functionality to work either if this was the case.

---

Are you building with CMake or with the Makefile builds?

And have you tried to see if the error persists if you set the SDMMC I/O to 1-bit, and a slower speed, while still using the DMA?
I'd be surprised if the bus width would affect stability between polling and DMA, but worth checking.

[CyberDuck79]

@stephenhensley I already investigated this memory location problem previously, but it was OK.
There is a possibility that I just did not succeed in reverting my SD card handling code to the proper configuration, as I have to implement some tweaks to support my libdaisy fork changes (polling).

Like I said, for my current needs, my fix is sufficient, so for the moment, I continue to focus on my main goal:
A Plaits port for Daisy Patch (would be published on Electro-smith Forum / Discord in the not-too-distant future).
I plan to port other MI modules that could require saving samples to the SD card. At that moment, I guess I would take time to investigate more deeply.

[CyberDuck79]

OK it was effectively a DMA buffer placement problem.
The DMA_BUFFER_MEM_SECTION points to D2 SRAM which works for most DMA but not SDMMC's IDMA.
SDMMC1's IDMA cannot efficiently access D2 SRAM (0x30000000). It needs to use AXI SRAM (0x24000000).

I was able to debug that with these changes: #685 and additional changes to capture the precise error (HAL_SD_ERROR_TX_UNDERRUN), I have not included them in the PR because this is only useful for precise diagnostics.

[stephenhensley]

Thanks for the updates!

Also ports of the MI modules sound cool! Looking forward to seeing how they come out :)