FATFS f_write, writes wrong content when source/destination buffer is in CoreCoupledMemory with the use of DMA template using CubeMx.

[RHerm]

Our setup:

- We use DMA2 controller in conjunction with SDIO to use the physical SDCard.

 Given : We choose to put the STACK into core coupled memory (only accessible by CPU), since this reduces the DMA latency (see AN4031 Rev3, chapter 2.1.3).

 - The problem we now have is that we cannot use local variables (which are placed on STACK) to transfer data to SDCARD, we must declare it as static variable which is not default usage and for new to write code fault prone.

     - the problem from the local variable (which is placed at STACK which is in core coupled memory) is that the DMA controller cannot access this memory.

                 - the major problem is that it doesn't give back a fault, The file is written but the contents are not equal to the expected buffer contents.

                - when declaring the fileobject and the buffer as static variable, it works as expected.

- Why does't the DMA give an error or coop with this situation, so that one knows that this transfer was really successful?

Regards,

Rene Hermans.

[Tesla DeLorean]

Assuming an F4 part.

One could certainly add sanity checking of address range and alignment in the DISKIO layer. ST has opted for a simple demo of functionality, not a robust commercial grade implementation. Other platforms you need to watch cache coherency issues very carefully.

I'll note that f_write is going to be hugely inefficient with small writes, so some buffering will help a lot.

Not sure why the DMA and code don't throw a fault in this situation​.

[berendi]

> we cannot use local variables (which are placed on STACK) to transfer data to SDCARD

Using local variables for asynchronous I/O is very fault prone as well, as they might go out of scope before the transfer is complete.

> Why does't the DMA give an error or coop with this situation, so that one knows that this transfer was really successful?

Hardwiring convenience features would introduce more complexity to the hardware. It would cost time and money to design, implement, test and manufacture it.

[Tesla DeLorean]

>>..is very fault prone as well, as they might go out of scope before the transfer is complete.

+1 Yes DMA may out live the life of the variable scope, very problematic.