FatFS f_read returns FR_DISK_ERR

I am attempting to load a WAV file from an SD card on the Daisy Patch. I’m able to browse the contents of the card, but when I attempt to use f_read it returns FR_DISK_ERR.

This is my open function that attempts to read the file. I have adapted it from an earlier project of mine for an ST development board where it is working fine. The f_open and f_lseek calls are both successful, any ideas why f_read might fail this way? I’m able to browse the card before and after the failed read, so I think the configuration is mostly okay.

bool FileHandle::open(const char* fileName)
    FRESULT res;  
    FIL     waveFile;
    UINT    bytesRead;

    char filePath[256];
    sprintf(filePath, "%s/%s", fileSystem.getCurrentPath(), fileName);

    debugPrint("FileHandle::open( %s )\r\n", fileName);
    debugPrint("current directory: %s\r\n", fileSystem.getCurrentPath());    
    if((res = f_open(&waveFile, filePath, FA_OPEN_EXISTING | FA_READ)) != FR_OK)
        debugPrint("Unable to open WAVE file '%s'\r\n", filePath);
        return false;

    if((res = f_lseek(&waveFile, 0)) != FR_OK)
         debugPrint("Unable to seek, %s\r\n", getFatFSErrorCode(res));
         return false;

    // Read and validate the RIFF header
    if((res = f_read(&waveFile, &m_waveDesc, sizeof(WaveDesc), &bytesRead)) != FR_OK && bytesRead != sizeof(WaveDesc))
        debugPrint("Invalid WAV file, %s\r\n", getFatFSErrorCode(res));
        return false;

I ran the HardwareTest project, and the SD test passes. Looking at the code, there is a comment that holds the key to this puzzle:

FIL            file; /**< Can't be made on the stack (DTCMRAM) */

So it seems that I will need to use global or heap-allocated FIL objects.

Yes, this requirement is due to DMA limitations for the SDMMC peripheral. It can only access data in the D1 RAM section.

It’s actually possible to overcome this and access other memory regions if they start using a scratch buffer for SD card operations in libDaisy. But it would incur some performance loss for the extra data copying.

Now that I think about it, I seem to remember taking this into consideration when setting up the linker script for my ST project. But that project is a few years old now so it had slipped my mind. Thanks for the reminder.