FR_LOCKED issue when writing to file with FATFS R0.12c over SDIO

[JBond.1]

Hi, I have STM32F407 and trying to write log file (in main loop) with FATFS R0.12c over SDIO.

But after few writes I get error:

FR_LOCKED // (16) The operation is rejected according to the file sharing policy

Previously I was using STM32F103 and was writing to log file using same algorithm with FATFS R0.11 over SPI without this issue. So I suspect the issue should be in "FATFS R0.12c" or "SDIO"?

What could be the issue and how could I fix this?

[JBond.1]

It seems that first I am getting

FR_DISK_ERR // (1) A hard error occurred in the low level disk I/O layer

from f_lseek.

And after that it becomes

FR_LOCKED // (16) The operation is rejected according to the file sharing policy

[JBond.1]

Why do I get FR_DISK_ERR on f_lseek?

[Tesla DeLorean]

Who knows?

Probably has an issue loading and walking the FAT Table.

Instrument the DISKIO layer so you can establish the point of failure and the error the underlying driver code is reporting.

[JBond.1]

OK, with your encouragement I did dig deeper. I set the break point in "bsp_driver_sd.c" where it returns "hsd->ErrorCode" from "HAL_SD_ReadBlocks":

__weak uint8_t BSP_SD_ReadBlocks(uint32_t *pData, uint32_t ReadAddr, uint32_t NumOfBlocks, uint32_t Timeout)
{
  uint8_t sd_state = MSD_OK;
 
  if (HAL_SD_ReadBlocks(&hsd, (uint8_t *)pData, ReadAddr, NumOfBlocks, Timeout) != HAL_OK)
  {
    sd_state = MSD_ERROR; // break point, check hsd->ErrorCode 
  }
 
  return sd_state;
}

Writing to file sometimes works, but eventually it returns "hsd->ErrorCode = 0x20" which means HAL_SD_ERROR_RX_OVERRUN:

#define HAL_SD_ERROR_RX_OVERRUN SDMMC_ERROR_RX_OVERRUN //!< Receive FIFO overrun
#define SDMMC_ERROR_RX_OVERRUN 0x00000020U //!< Receive FIFO overrun

How do I fix HAL_SD_ERROR_RX_OVERRUN?

I dont use DMA, my settings

[JBond.1]

Could this be caused by the setup of CAN1/SPI3/USART2? Do they use same FIFO or something?

I have tried to increase "hsd.Init.ClockDiv", but id does not seem to solve the problem.

Could I somehow wait for FIFO to be available in my code? Is there somethink like f_waitForCompletion?

[Tesla DeLorean · Accepted solution]

No they all have their own FIFO.

What however is critical is not to get distracted in the middle of SDIO transfers, the FIFO protects you somewhat, but you can't go off into other interrupts/threads for prolonged periods.

DMA would be preferable.

In polled you might want to look at the SDIO peripheral library, perhaps optimizing the aligned memory case, or using a "critical section"

[JBond.1]

I do SDIO write on main loop, but there are TIM2/TIM3/CAN1 RX0/CAN1 RX1 interrupts which has other logic. So those interrupts are to blame if they occur during SDIO write?

What could be the possible solution to such problem? Only reducing interrupt duration? Or would using DMA and setting all SDIO interrupts to higher priority help?

[C. Mart]

Hello! Did you find any solution? I'm having a similar issue. FR_DISK_ERR, tracked down to BSD_SD_ReadBlocks, deeper into move_window() (ff.c) -> disk_read() (diskio.c). Also SD_Read() returns res = RES_ERROR, probably this is all connected, I'm a bit stuck. I'd appreciate any help, thank you :)