cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 OCTOSPI immediate write after read fails deterministically.

nkartik
Associate

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.

nkartik_0-1769028000749.png

 

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) addressSizeResult
0x9000 00002 MBTest passes (also for 0x9020k,0x9040k, 0x9060k resp.)
0x9010 00002MBTest fails, around 0x9020 0000. 
0x9030 0000, 0x9050 0000 respectively2MBTest fails, around 0x9040 0000 and 0x90600000 respectively.
0x901FF0002 kBTest 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 word

The 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 word

I 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?

0 REPLIES 0