2024-07-18 03:45 AM - edited 2024-07-18 08:09 AM
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.
I forgot to mention in the initial description above that if the "SDRAM write 1" is removed, then the data read back matches the "SDRAM write 2".
Kind regards
2024-07-18 04:06 AM
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.
2024-07-18 04:29 AM
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"?
2024-07-18 06:04 AM
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.
2024-07-18 08:08 AM - edited 2024-07-18 08:10 AM
Hi TDK,
Yes. The behavior is repeatable. When reading back the buffer, the 0xFF are always observable in the same position in the buffer.
Yes. The board is a custom one.
In an attempt to check whether it could be a cache issue, I tried to configure the FMC/SDRAM MPU region as non-cacheable, but the behavior remained the same. (For context, the application is Zephyr RTOS based and I changed this setting using Zephyr's device tree: changed "zephyr,memory-attr = <( DT_MEM_ARM_MPU_RAM )>;" to "zephyr,memory-attr = <( DT_MEM_ARM_MPU_RAM_NOCACHE)>;". I could not go into the kernel weeds to confirm if this change did what I was looking for as at the moment I am not familiar with it). So either this update didn't do what I was looking for or this is really not a cache issue.
One, perhaps important, detail that I forgot to mention in my initial post (apologies for that) is that if the "SDRAM write 1" is removed, then the data read back matches the "SDRAM write 2".
Have you got any suggestions on how I could continue this investigation?