Does someone tested an external sram (16Bit) with Abraham memory test?

[DFuchs]

Hi!

I have an external sram connected to a STM32H743. It has a 16 bit wide data bus.

I started a memory test and got lots of errors. So i had to look at the data in the sram with STM32CubeIDE 1.30.

For example:

I fill the complete memory with 0xFFFF. (no problem)

I'm writing 0x0000 at address 0x60001000. (no problem)

I'm writing 0x0000 at address 0x60001002. (no problem)

...

I'm writing 0x0000 at address 0x60001020. The data are set to 0x0000 at address 0x60001022, 0x60001024 and 0x60001026 too. :(

If i start with a higher address the error is at the address plus offset 0x20 :\

c++ code looks like:

*reinterpret_cast<uint16_t volatile*>(0x60001000) = uint16_t(0);

*reinterpret_cast<uint16_t volatile*>(0x60001002) = uint16_t(0);

...

FMC bank1 is set to sram (0) and 16bit width (1). Write FIFO is disabled. Data cache is disabled.

The data inside the ram is also not correct without starting the ide.

Why does the FMC generate four Writes? Do I have to change the configuration of AXI Target 5? Is there another fifo or cache?

Can anybody give me a hint?

Kind regards

Daniel

[TDK]

> external sram connected to a STM32H743

How are they connected? Soldered on a board with proper trace lengths, etc?

Does it work if you reduce the clock speed? Might just be incorrect timing settings.

[waclawek.jan]

> I fill the complete memory with 0xFFFF. (no problem

What does it mean? How do you know there's no problem?

> I'm writing 0x0000 at address 0x60001000. (no problem)

Again, how do you know? Is there only one WR pulse with that write? Do you observe the bus using LA?

This might be related to https://community.st.com/s/question/0D50X00009XkWQESA3/stm32h743ii-fmc-8080-lcd-spurious-writes - the common denominator is "disabled data cache".

Btw., 0x20 is one cacheline. However, in the linked thread, there is no evidence of the problem being "shifted" by 0x20.

JW

[Tesla DeLorean]

Data cache, write back vs thru and write buffers will tend to make diagnosis more difficult. Best to disable all

Cache lines are 32-byte wide as I recall

Sanity check address pins, settings and connectivity. Could access device via GPIO (ODR, IDR), walk the bits checking for stuck at, or shorted pins.

Personally prefer use of LFSR writing unique data to each cell, rather than incrementing counts.

[DFuchs]

Thank you!

Writing 0xFFFF wil show the same problem after 0x20 bytes.

The first 0x0000 doesn't overwrite the next three 16bit words. I have to look if there are three other WR pulses.

Probably i must attach our fast oscilloscope. It has up 16 channels logic analyzer too. But it's no fun to get it all connected.

Kind regards

Daniel

[DFuchs]

Thank you!

It's soldered on our own prototype board. Trace length shoul match.

Same problem with slower clock speed.

Kind regards

Daniel

[DFuchs]

Thank you!

Good idea to make a test per GPIO.

But now i read your message and the link waclawek.jan posted. I think i had to configure the MPU to treat the SRAM as device memory.

I've to test it.

Kind regards

Daniel

[DFuchs]

Thank you all!

Easiest solution for me is to remap the SRAM from 0x60000000 to 0xC0000000. I made no other changes and it works.

Perhaps i will try the solution with the MPU too.

Kind regards

Daniel

[berendi]

0xC0000000 is not cached. So the problem is not solved, it may resurface when you access it in a pattern similar to what the cache does.

[waclawek.jan]

>So the problem is not solved, it may resurface when you access it

>in a pattern similar to what the cache does.

And do you have the perseverance to get to the root of it? I have ideas what to try, but I don't have hardware nor time, and my interest is primarily academic/general curiosity.

I personally dropped the idea of using a higher power mcu when I attended the F7 seminar in Prague back then and understood that the complexity behind the bus system and caches is far beyond what the available documentation explains, and is generally solved by massive handwavings and general pointing to the impressive Coremark score. It may be good for general purpose computing, but I prefer to be in control of my controllers.

JW