electro-smith / libDaisy

Hardware Library for the Daisy Audio Platform
https://www.electro-smith.com/daisy
MIT License
312 stars 131 forks source link

SDCard - HAL_SD_ERROR_RX_OVERRUN with .bss in DTCMRAM #490

Open AndrewCapon opened 2 years ago

AndrewCapon commented 2 years ago

It has taken me a while to track this one down!

Trying to read from the SDCard when .bss is in DTCMRAM causes a HAL_SD_ERROR_RX_OVERRUN, this is set in the interrupt handler HAL_SD_IRQHandler() and caused by a SDMMC_IT_RXOVERR.

The sram linker script is putting .bss in DTCMRAM, I guess there must be some static vars that do not like being in here effecting it.

Change this to SRAM and everything works fine.

stephenhensley commented 2 years ago

Thanks for bringing this up. The SDMMC is unique in that it has limited access to on-board memories:

image

So you can use the SRAM, or the external SDRAM for FIL objects, etc. that directly interact with the SDMMC1 data registers.

It might be worth separating off a small chunk of space within the SRAM-execution linker that can still be used for SDMMC accesses. However, the user would still have to know to place them there.

AndrewCapon commented 2 years ago

Hi Stephan,

I am also having problems unrelated to this with SDCard access.

Just using the normal flash linker script I am getting the same SDMMC_IT_RXOVERR when calling f_read(), also f_write() is failing silently.

The reads from the f_mount previously work fine, as do f_open() and f_close()

Very strange, I will knock up a basic test case tomorrow that maybe someone else could test, maybe there is an issue with my field.

I have tried changing to Speed::Slow to see if that helps but it didn't.

stephenhensley commented 2 years ago

@AndrewCapon hmm, that sounds like what may happen if you're allocating any of the FIL, DIR, or FATFS objects on the stack or heap (which is in DTCMRAM by default).

The new FatFSInterface object has a global FATFS instance available for each possilbe media (SDMMC / USB) that have their own getters.

For FIL and DIR objects that will directly touch the SDMMC, I usually declare them all somewhere globally so that they end up in the AXI SRAM region.

If you are getting the error and have verified that any such objects are located in AXI SRAM then there may be another issue, and our team can certainly look into it further.

AndrewCapon commented 2 years ago

Hi @stephenhensley

You are spot on, all working now. Thanks very much for the info.

Andy