We are using an STM32L452, running directly from an HSE crystal at 8 MHz (i.e. no PLL), using the SDMMC peripheral with an SD clock of 8 MHz, and DMA for transferring data to and from SDMMC.
We're also using the SD, DMA and FATFS library code generated by STM32CubeMX v5.0.0, modified in the user code areas, due to some serious bugs in the library, for which I will be submitting separate bug reports.
When a large number of back-to-back reads are executed, there is a chance of a read failing (approximately 1 per 10,000 reads, at least for our application), and it always fails in exactly the same way, namely: SDMMC reports that it's finished, but DMA indicates that is has precisely 1 byte left to read. It always fails on a single-packet read, never a multi-packet read, nor any write.
Nothing that we have tried prevents this, including altering clock rates, or changing SDMMC settings. HW flow control is required, otherwise we immediately see a tx underrun on writes.
Note that, in our firmware, all SD operations are controlled by a single thread, and operations are blocked by a semaphore until either the interrupts complete, or a timeout occurs.
In the absence of any way of preventing this failure, we instead detect it after a timeout of 1 s, abort the stalled DMA operation, and then retry the read with the same parameters. This has proven to be very successful.
Despite this, we'd obviously rather avoid the issue in the first case. So, can ST either suggest a way of avoiding the issue, or confirm that this is a hardware bug?
