cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H745 and ISDRAM - S42S32800J-7BLI communication issue

ABora.4
Associate III

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

1 REPLY 1
BarryWhit
Senior III

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

- What does each line represent? What does is 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 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?

 

 

 

- If a post has answered your question, please acknowledge the help you received by clicking "Accept as Solution".
- Once you've solved your issue, please consider posting a summary of any additional details you've learned. Your new knowledge may help others in the future.