STM32F7 data corruption when using SPI with DMA in SRAM1 instead of DTCM

[STsch.1]

Hi,

From the errata sheet I have seen, that the STM32F7x2 has a problem with the cache in write through:

Errata:

https://www.st.com/resource/en/errata_sheet/es0360-stm32f72xxx-and-stm32f73xxx-device-limitations-stmicroelectronics.pdf

Datasheet:

https://www.st.com/resource/en/reference_manual/dm00305990-stm32f72xxx-and-stm32f73xxx-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf

I'm unsure about this, if it could occur in my current implementation. I enable the I-cache and the D-cache, but I don't know how I can check, if it is in write through or not.

Now about the behaviour: When I use the DTCM RAM section for the application and make some SPI readings with DMA from an IC, I never get a crc error. But when I use the SRAM1 section for the application, I get around 5 crc errors a second (around 10k reads a second). So this is very strange behaviour and also the reason I found this in the errata sheet. Might the cache issue here be the problem?

Settings:

[Danish1]

My reading of that errata item suggests that it only affects the arm core writing through to the memory.

But independent of that errata item is the fact that there is a cache between the arm core and SRAM1. Unless you either disable the cache for that portion of SRAM1 where you DMA into, or invalidate the cache appropriately once DMA completes, it is possible that you will still have some of the old (pre-DMA) contents in the cache. So when the processor tries to read what has come in from the SPI, cache hits will return the old data; cache misses will read the new data. And this mix of old and new data will fail crc.

I personally disable the data cache for all areas of SRAM where I DMA to / from.

Others prefer to do flush / invalidate as appropriate just before / after DMA read / write.

I have not attempted to measure the relative performance of the two approaches.

Hope this helps,

Danish

[STsch.1]

Ok, thank you for your answer. The strange thing is, that I don't have this for the DTCM, but only for the SRAM1? I also check always for the DMA_Callback to ensure, that the DMA finished the writing, so this should not behave like that.

So if it is a cache problem, what is the difference between the cash for SRAM1 and DTCM?

[Danish1]

The arm core accesses DTCM directly - there's no cache in that path.

[STsch.1]

Ah ok, thank you. So that is the reason I have no CRC errors there. So this problem from the errata sheet does only apply, when the core uses the SRAM1 and not when I use DTCM only?

[waclawek.jan]

> So this problem from the errata sheet does only apply, when the core uses the SRAM1 and not when I use DTCM only?

Yes.

But, also, write-through applies to... well... write to SRAM from processor. Your problem is with *reading*. That's why you want to invalidate cache after DMA finished an before reading.

https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices

(It says H7 but applies to F7 too)

JW