STM32H745 and ISDRAM - S42S32800J-7BLI communication issue

[ABora.4]

Hello,

In my current project, we are using MCU - STM32H745Xi and integrated with SDRAM - IS42S32800J-7BLI.
As of now, we are accessing 3 location of SDRAM to write and read the data and below are the observations:

• When we write the data and read it immediately we are able to read it properly and with correct value.
• When we re read the same location, we get different data that the previous may be corrupted data. Logs for the same are attached for your reference.
• The SDRAM is configured in CAS latency 3 and operating frequency of the controller for SDRAM is 120MHz.
• SDRAM timings are set as per above configuration and is verified on the another custom board.
• We have make 3 proto board and we are facing this issue on 2 boards out of 3.
• Data lines are kept PULL UP internally(from software) during initialization 
• If we store the data in non cache region of the SDRAM, the issue is observed as mentioned above.
• If we store the data in cache region of trhe SDRAM then there is no issue, we get the correct data value except  unwritten location of the SDRAM but after write the data on that location, it shows correct every time.
• We have also do the same exercise with internal flash of MCU and it always gives us the corrected data.
• Currently we are using 256Mb memory.

Please find the below attachments for your reference and provide your valuable guidance to resolve it.

Let me know if you need more information.

Regards,

Alpesh

[BarryWhit]

- Can you explain what the program that generated the log is actually doing?

- What does each line represent? What does the first field (0/1/2) supposed to indicate?

- In the case of bad values, what were the correct values that should have been there?

The definite pattern to the errors suggests a logical rather than electrical problem.

The fact the 2/3 board exhibits the problem suggests that you may have a marginal design.

Is it possible to transpose the good chip to one of the "bad" boards and rerun the tests? if the good chip also works on the bad board, it is probably a timing issue and the good chip's silicon simply came out better.

Can you dial down the frequency and retest? relax the timings and retest?

How does your PDN look? did you follow manufacturer recommendations on decoupling capacitors?

[ABora.4]

Hello,

We have down the frequency to 80MHz but the result is the same.

Yes, we have follow the decoupling capacitor as per the recommendation. We have also follow the Impedance, length match.

We will try by changing the SDRAM with new one and update you the result here.

Regards,

Alpesh

[BarryWhit]

> - Can you explain what the program that generated the log is actually doing?

> - What does each line represent? What does the first field (0/1/2) supposed to indicate?

> - In the case of bad values, what were the correct values that should have been there?

[ABora.4]

Hello,

The field 0/1/2 represent the address of the memory on which we write the values. So here we use first three address to store the data and read back from the same three addresses.

First we write the value 0 X X

Second line it should be 0 1 X

Third line should be 0 1 2

Fourth line should be 3 1 2

Fifth line should be 3 4 2

Sixth line should be 3 4 5

7th  line = 6 4 5 

8th  line = 6 7 5

9th line = 6 7 8

and so on...

So for example from line 4th to 5th , there should be write 4 instead of 1 and other values should be same as previous(3 and 2) but that previous values are changes to different number so please match this data with the previously share image.

Regards,

Alpesh

[BarryWhit]

Can you post the configuration you're using for the FMC?

Does this code produce a running counter with 1sec interval, or do you see corruption as well?

while(1){
  *p=cnt++;
  HAL_Delay(999);
  printf("%d",*p);
}

In uncached mode, what happens if you access the memory as an array of uint32_t?

This test will may not do anything when cache is on, since the cache is large enough to hold 3 values without ever being forced to evict data and reread anything from SDRAM. Try the following test instead. In cached mode, write pseudo-random data to entire chip and only then read back and compare every value you wrote. Do you get errors? (you can use an LFSR and reset its state after filling chip, so you can regenerate values for compare)?

[ABora.4]

Hello,

Please find the attached file which includes FMC Configuration and other details which you are asking.

Kindly check and provide your valuable input.

Regards,

Alpesh

[BarryWhit]

The datasheet says that, for a -7 device, tXSR (for example) needs to be at least 70 ns.

In the timings you posted you have set

  SdramTiming.ExitSelfRefreshDelay = (8-1);

But 8 clock cycles at 120Mhz (your stated clock freq) is only 66.67ns.

You have similar errors in other timing values as well, so it's no wonder you're seeing data corruption.

[ABora.4]

Hello,

Please find the clock tree and the calculated timing diagram.

I will check the clock from 8 cycles to 9 cycles for 75nS self refresh time.

Is there anything need to change to resolve the issue?

Regards,

Alpesh

     

[BarryWhit]

> Is there anything need to change to resolve the issue?

It's not my job to fix your board, someone is paying you to do it.

As I already said, review ALL your memory timing for errors.