Yes, managing cache coherency is important when using DMA and caching, but ideally, this should be handled by the driver itself. Functions like f_open or f_write should work without requiring manual cache management from the user. If the user has to call SCB_InvalidateDCache_by_Addr() after reading or SCB_CleanDCache_by_Addr() before writing, it indicates that the driver is not handling cache coherency properly. This is not the user's responsibility, and if this behavior is necessary, it means the driver is malfunctioning.
Given that this driver is included in CubeMX, it should function correctly without requiring additional steps when enabling DCache. If it doesn’t, it’s a sign that the driver isn’t working as expected.
I tried the file you sent me, but I encountered an issue. The functions it calls, like BSP_SD_Init, have different arguments. For example, the one generated by CubeMX has no arguments, while the one used by the new driver requires an instance, and this is the case with all the functions. Given this, unless I’m mistaken, I believe they are not compatible. In other words, when I generate code with CubeMX, it generates functions that are incompatible with the new sd_diskio.c, so the only solution I see is to remove FAT_FS from CubeMX and manually add all the code. If that’s the case, it’s clear that this driver should be updated because it’s not compatible with CubeMX. If that’s not the case, I would appreciate it if you could explain how I should proceed.
