I’m having problems with a a patch.Init() and the SD card reader when I use the bootloader to put the binary in SRAM.
To rubberduck my problem, I’ve just been using the DaisyExamples HardwareTest and just adding
APP_TYPE = BOOT_SRAM to the Makefile, and the test outputs show the SDMMC failing, oddly when I change it to
APP_TYPE = BOOT_QSPI, then everything works fine. My project is too big to fit onto flash, so my understanding is that SRAM is the best thing to do here. Is the bootloader looking for a binary on the SD card?
Adding a bunch of debugging prints, and nothing is immediately obvious to me what I could be doing wrong. Any ideas?
Further diving is showing that there’s issues with the FatFSInterface and the bootloader:
This object has some memory limitations due to the media connected to it. The SDMMC1 peripheral can only communicate with the AXI SRAM, and the DTCMRAM cannot communicate with the DMA. So the FatFSInterface object should always be located in the AXI SRAM. This is the default location for all data/bss memory using the standard build. However, applciations using the electrosmith bootloader will need special consideration when using this object AND an SD Card.
So at least there’s a string to tug on.
You’re right that SDMMC DMA being the issue preventing it from working under this conditions. That hardware test file moves 2 objects from stack (that’s always on DTCM) to
.data section by making it global, but when application is in SRAM that ends up in the same DTCM sectioin. Can’t test this myself ATM, but maybe changing it to something like this can do the trick:
#define DSY_TEXT __attribute__((section(".text")))
DSY_TEXT FIL file; /**< Can't be made on the stack (DTCMRAM) */
DSY_TEXT FatFSInterface fsi;
I would expect that to move them to text section which is on SRAM. It’s already used for program code, but also other stuff like constants. Adding data to it is probably fine.
This works like a charm (so far), thanks so much!