2026-01-21 12:48 PM - edited 2026-01-21 12:56 PM
Introduction: While testing the U575 with external PSRAM connected over OCTOSPI1, certain memory test scenarios fail deterministically.
Setup:
Using a STM32U575, connected on OCTO-SPI1 to PSRAM (IS66WVH8M8) 8MB in size. The STM is configured in memory mapped mode, hyperbus enabled, no DMA or Cache enabled, & wrap/burst mode disabled.
While testing the PSRAM using Barr tests, found that the data bus and address bus test pass, but the device test had a deterministic pass/fail behavior.
The device test passed for any size as long as the test wasn't crossing the 2MB boundary.
| Base (start) address | Size | Result |
| 0x9000 0000 | 2 MB | Test passes (also for 0x9020k,0x9040k, 0x9060k resp.) |
| 0x9010 0000 | 2MB | Test fails, around 0x9020 0000. |
| 0x9030 0000, 0x9050 0000 respectively | 2MB | Test fails, around 0x9040 0000 and 0x90600000 respectively. |
| 0x901FF000 | 2 kB | Test fails around 0x9020 0000. |
While debugging/analyzing code found something interesting -
The original device test looks like this: ( The tests included word_size as 8/16/32 bits)
Device test(base, size)
for loop : size/word_size
write a pattern for each word
for loop: size/word_size
read, check if pattern match for each word
write antipattern in each word
for loop: size/word_size
read, check antipattern for each wordThe interesting find is that when the write antipattern step in the second for loop is moved out into a separate for loop, the test passes for all scenarios (and also for word_size i.e. 8/16/32 bits). Here is how the modified code looks:
Device test(base, size)
for loop : size/word_size
write a pattern for each word
for loop: size/word_size
read, check if pattern match for each word
for loop: size/word_size <=== new one
write antipattern in each word
for loop: size/word_size
read, check antipattern for each wordI re-read the errata and found 2.6.7, 2.6.8, 2.6.10 to be interestingly close but aren't the same case.
As a final measure, I tried inserting NOPs in the original code between the read and writes, and also after the writes, but the test still failed, so it was not just about NOPing.
Since the application will use the PSRAM as on-board RAM, it only seems plausible that there could be a use case where a read could be followed by a write.
Is there something simple and fundamental that I'm missing here?