cancel
Showing results for 
Search instead for 
Did you mean: 

FMC: Data integrity in SDRAM

BrMel10
Associate II

Hi everyone,

I am observing some data corruption in an external SDRAM connected to an STM32 F7 FMC peripheral and I am trying to understand what is happening and how to prevent it.

 

Scenario:

  • Configure the FMC to interface with a Winbond external SDRAM chip
  • Allocated a static memory buffer in the external SDRAM (somewhere in the 0xC000 0000 to 0xCFFF FFFF region)
  • SDRAM write 1: reset the whole buffer to a known value [memset(0xFF)] to be sure buffer contents are in a known state
  • SDRAM write 2immediately after SDRAM write 1, populate the buffer with my data of interest
  • immediately after SDRAM write 2, read the buffer and notice the data corruption. I.e., in the middle of my data of interest, some 0xFF are still present (figure bellow).

BrMel10_1-1721299239655.png

 

My theory:

  • my theory is that when we write to the memory in the external RAM, we are not actually “writing to the memory in the external RAM”. We are in fact writing to the FMC SDRAM memory mapped region (0xC000 0000 to 0xCFFF FFFF) and then, in the background, the FMC peripheral updates the external RAM... which takes some time. So when "SDRAM write 2" operation starts the FMC is still updating the SDRAM as requested in the "SDRAM write 1" step. So at this point the FMC has to simultaneously reflect in the SDRAM the "SDRAM write 1" and "SDRAM write 2" causing a concurrency problem leading the data reading showing some 0xFFs in the middle of the data of interest

 

Where I need help:

  • Is my theory / understanding described above correct? If not, what am missing?
  • If so, is there a way to make sure that the "SDRAM write 2" to the SDRAM only occurs once the "SDRAM write 1" has finished?

 

 

Kind regards

3 REPLIES 3

The write buffers aren't that deep

The cache would be the thing implementing write-back vs write-thru the former occurring at line eviction. 

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Hi Tesla,
sorry for my ignorance.

If I understand you correctly, my theory is wrong and the issue I am facing is not related to concurrency / timing access from the FMC to the external SDRAM but caching issues. And also that if the caching is set to "write-through" then the issue should not be observable

Could you share how do we control the FMC caching in the STM32 F7 MCU?

How do we check which "write-through" vs "write-back" is set and how do we change it to "write-through"?

TDK
Guru

Is this repeatable? Is the same memory region 0xFF after reading it back? If not, I would expect this is a hardware or signal integrity issue. Is this a custom board? Does not look like a cache issue because it appears in the middle of a large buffer.

If you feel a post has answered your question, please click "Accept as Solution".