Skip to main content
DFuchs
DFuchs
Associate III
May 6, 2020
Question

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

  • May 6, 2020
  • 4 replies
  • 4316 views

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

This topic has been closed for replies.

4 replies

TDK
TDK
Super User
May 6, 2020

> 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.

"If you feel a post has answered your question, please click ""Accept as Solution""."
DFuchs
DFuchsAuthor
Associate III
May 7, 2020

Thank you!

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

Same problem with slower clock speed.

Kind regards

Daniel

waclawek.jan
waclawek.jan
Super User
May 6, 2020

> 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
Tesla DeLorean
Guru
May 6, 2020

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.

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
DFuchs
DFuchsAuthor
Associate III
May 7, 2020

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
DFuchsAuthor
Associate III
May 7, 2020

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
berendi
Principal
May 7, 2020

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
waclawek.jan
Super User
May 7, 2020

>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

berendi
berendi
Principal
May 7, 2020

> And do you have the perseverance to get to the root of it?

Yes, I can be quite stubborn, especially if it happens in a project that we intend to sell to real customers. Problems like that can turn them into angry customers in the best case, and me into an unemployed man in the worst case.

> I prefer to be in control of my controllers.

Sometimes we have to make compromises. It gets several orders of magnitude worse in the MPU world.

waclawek.jan
waclawek.jan
Super User
May 7, 2020

> Yes, I can be quite stubborn

I never doubted that. I asked the wrong question. What I really meant above, do you offer to volunteer to investigate this item deeper? Note that this is an unfair request: myself said above I won't.

>MPU world

I'm acknowledging the methods of that world, but they leave me unimpressed.

JW

Terms & ConditionsAccessibility statement