STM32H735 OCTOSPI2 Hyperram Errors

[HSamm.1]

Using the STM32H735G-DK with on board external memory connected to OCTOSPI2.

I'm using the demo code for this board to initialise the OSPI2 interface and to access the on board HyperRAM (S70KL1281DABHI023).

The demo code writes 32-bits and reads them back immediately to compare, going over the whole SRAM address space and finds no discrepancy. However some time later a number of the cells have changed.

Modifying the test to write all ones to all cells and read back in the next round shows no errors also. But writing all zeroes I find non zero cells on the second run through.

It doesn't seem to be a defect as I have two boards and both expose the same behaviour.

Any idea?

[JanHollburg]

If the RAM corruption is unrelated to the software actions in your code, the first thing I would suspect is the power supply. If you're powering the board over your PC, maybe the USB port or the cable is the weak spot. Try using something with a lower impedance (that means, less voltage drops on power spikes)

[David Littell]

Sounds like the old-time "DRAM fade" due to a refresh rate problem, something that's not supposed to happen with HyperRAM, right? Any progress/resolution on this?

[HSamm.1]

As far as I remember it was a cache coherecy problem. Data wasn't going to the HyperRAM unless I put in frequent calls to SCB_CleanDCache_by_Addr(). The apparent 'fading' was due to data in the cache being invalidated without automatically flushing to the HyperRAM. When you read some time later, you get stale data from the HyperRAM. This is different with native RAM.