STM32L452 + SD + DMA + FATFS + STM32CubeMX v5.0.0: 32-bit alignment check is needed

[Steve Melnikoff]

The functions SD_read() and SD_write() in sd_diskio.c do 32-bit DMA accessed to the SDMMC FIFO. As a result, any buffer passed to these functions must be 32-bit aligned, as otherwise data can be lost or corrupted.

However, it is not enough to pass an aligned buffer to f_write() and f_read(), as there are various scenarios where the buffers passed to SD_write() and SD_read() are still not aligned.

So the latter functions need to check for an unaligned buffer, and take some action to correct this. We found that the simplest fix is to have a local aligned buffer, one sector in size, which can be used for DMA operations, with data transferred between it and the buffer passed to the function.

We've never seen a case where more than one sector is read/written and an unaligned buffer is passed in; it's possible that this scenario is impossible.

Incidentally, this post mentions a scratchpad, which sounds similar to our solution. If this isn't already included in the version of this file for STM32L4, could this be added in the near future?

----

This is the sixth bug report I've filed recently, relating solely to the SD code produced by STM32CubeMX. Only one has had a response from ST, and that was a holding message, with no further update in the 2 months since.

Please could ST provide some reassurance that these bugs are being looked into.

@Imen DAHMEN​ @Amel NASRI​ @Maurizio NESSI​

[Tesla DeLorean]

>>We've never seen a case where more than one sector is read/written and an unaligned buffer is passed in; it's possible that this scenario is impossible.

FATFS typically does the one sector read/writes where the f_write/f_read operations span a sector. ie deblocking/media alignment

Also if you're doing small unaligned accesses to media via f_write/f_read performance will be brutal, your app needs to be more aware.

ST has had issues with block storage devices going back over a decade. I had posted (SPL days), and ST had lifted, a routine I had written which decomposed unaligned accesses to single accesses to an aligned buffer, it didn't care if these were single or multiple sectors, the code isn't any more/less complex either way. I don't see them using it any more, but the problem it addressed aren't any less real.

Any bugs in code I deliver are always my responsibility, assume you'll need to own whatever libraries you pull in, and whatever the automated crap generator outputs.

I'd care, but providing support is such a thankless black hole.

[Steve Melnikoff]

Hi Clive. Thank you for your response. In reply:

> FATFS typically does the one sector read/writes where the f_write/f_read operations span a sector. ie deblocking/media alignment

Yes, that was our conclusion too.

> Also if you're doing small unaligned accesses to media via f_write/f_read performance will be brutal, your app needs to be more aware.

Indeed. In this instance, it was an edge case that we only encountered after having no problems for some time; and the new scenario that led to this happening has since been removed.

> Any bugs in code I deliver are always my responsibility, assume you'll need to own whatever libraries you pull in, and whatever the automated crap generator outputs.

I totally agree. We have fixed or worked around all of the bugs we've encountered, and have reported them here only after we've solved the problem (and we've summarised what we did).

However, I feel that if ST provide code for everyone to use, then there is an implicit message that it should work in "normal" use cases - no matter how many disclaimers and caveats they may cite. Of the 6 bugs I've reported in the generated SD code, 5 may well depend on a particular setup or combination of conditions; but one of them is absolutely critical as, for this processor, the code simply fails to work at all without manual intervention.

> I'd care, but providing support is such a thankless black hole.

:) Yup. It's not your job to provide support here, so I hope that anyone you help is suitably appreciative of your time; but unless I've misunderstood, it is the job of the ST employees who frequent this forum. My experience so far, from the lack of response to the bug reports I've posted, has not been great, and it puts me off using ST products in future.

[Amel NASRI]

Hi @Steve Melnikoff​ ,

Just to comment on your last sentence: that is true we have an often presence of ST employees here, simply because this is the Community and not the official support channel. Official support channel relies on FAEs while Community relies on his members and Experts.

This is said, we try to review on priority reported bugs (with tag "Bug-Report").

Thanks for your understanding.

-Amel