STM32F429 SDRAM unreliable

[peterm]

Posted on October 20, 2014 at 02:18

I've copied the SDRAM hardware and software from the STM32F429 Discovery board. We've made a few boards so far. On some the SDRAM doesn't seem to work at all while on others it seems to work for a bit then get corrupted later on.

We're using it as a temporary RAM buffer for an LCD at the moment - the data is updated in the SDRAM then written out to the LCD via SPI. When the SDRAM works we get the expected screen. When it doesn't we get random garbage. Sometimes the whole screen is one colour (ie all the SDRAM has the same value). Sometimes as it goes down the screen it goes from black (0x0000) towards some colour (ie bits being set). Sometimes it contains random ''snow''. As far as I can tell (I've checked a number of times) the hardware is wired up the same. I'm using the same SDRAM chip. I've copied the

stm32f429i_discovery_sdram.c

code from the firmware package. I'm using the same 8MHz crystal. I tried changing the following settings but it made no difference (based on some other sample code)

  FMC_SDRAMCommandStructure.FMC_AutoRefreshNumber = 8;

  FMC_SetRefreshCount(680); I'm not sure where to start looking at it... help!

[Tesla DeLorean]

Posted on October 20, 2014 at 03:27

// MT48LC2M3B2B5-7E

// http://www.micron.com/~/media/Documents/Products/Data%20Sheet/DRAM/64mb_x32_sdram.pdf // IS42S16400J-7TL // http://www.issi.com/WW/pdf/42-45S16400J.pdf FMC_SetRefreshCount(1292); // 64 ms / 4096 * 84 MHz - 20   -> 15.625 (us) * 84 (MHz) = 1312.5 FMC_SetRefreshCount(1386); // 64 ms / 4096 * 90 MHz - 20   -> 15.625 (us) * 90 (MHz) = 1406.25 Signal integrity is important at 84-90 MHz, ie lengths and how signals are routed, supplies, decoupling. Timing parameters for the SDRAM will be dependent on the bus clock

[waclawek.jan]

Posted on October 20, 2014 at 09:09

> Signal integrity is important at 84-90 MHz, ie lengths and how signals are routed, supplies, decoupling.

+1 SDRAMs are surprisingly power hungry, have a look at the datasheet. This, together with the high-speed operation results in stringent requirement on quality power source and decoupling. Mind, you have to decouple tens of milliamps in tens of  MHz, otherwise you will see them on the ground/VCC all over your circuit. JW

[frankmeyer9]

Posted on October 20, 2014 at 09:16

Signal integrity is important at 84-90 MHz, ie lengths and how signals are routed, supplies, decoupling.

To achieve good signal integrity (i.e. low distortions and reflections), the impedance of the corresponding PCB lanes must match that of the input and output (or add termination resistors). I suggest a PCB design tool that includes a proper signal simulation, or try it outside. Measuring signals correctly at this frequencies is really tough ...

[peterm]

Posted on October 20, 2014 at 23:26

I initially had

  FMC_SetRefreshCount(1386); from the Discovery sample code - that didn't work so I tried the other values. The SDRAM chip is about 15mm from the STM32F429 - as close as I could get it. There are lots of 10nF/100nF/10uF caps sprinkled around to decouple it but no terminators (like the Discovery board...) Can I access the SDRAM at a slower speed? I'm not sure how to adjust the timing - I haven't used SDRAM before. From my understanding I can slow down the access times as long as I keep the refresh interval within specs - is there anything else to look out for?

[Tesla DeLorean]

Posted on October 21, 2014 at 01:26

Well the SDRAM part is already being clocked below specification, also not sure more rapid refresh is going to help here unless you have specific evidence it's loosing content over time.

I have more direct/recent experience with DDR, here termination is critical, as the bus isn't rail-to-rail, but rather above/below a reference threshold. You can slow the bus (and the processor), not sure if you are using 168 MHz (84 MHz) or 180 MHz (90 MHz) now. I will observe ST uses the 50 MHz pin slewing setting rather than 100 MHz in their GPIO configuration examples. You could definitely try less aggressive timings on the SDRAM Controller. Observation of the pins is going to be difficult, and will alter the pin characteristics. If this is a singular device on the data/address buses the situation with transmission lines is less complicated. I would initially focus on the supplies (hopefully you have planes, and there are just punch down vias to those). Check you have adequate bulk capacitance on your regulators, close up to the STM32, and for VCAP pins. Then focus on CLK, RAS and CAS signals for the SDRAM. I haven't looked at the series or termination resistors on the DISCO board, you might want to check what ST did there, and on the EVAL series boards. I would also look very specifically if the corruption has any patterns, either on the data bus, or the the address ranges.

[peterm]

Posted on October 21, 2014 at 02:23

Thanks Clive. It might take me a day or so to look at that - this is a side issue as it only affects the display.

It's a 6 layer board with the power/ground planes - the supplies punch down to them. I'm really hoping it's something I can solve with software!!

[glenn]

Posted on January 20, 2015 at 07:03

mcconaghy.peter

Did you find any solution to your problem? I am building a similar board and any heads up about hardware issues you found would be much appreciated. Also any software fixes that allowed you to continue.

[Tesla DeLorean]

Posted on January 20, 2015 at 17:40

Understand the existing designs, from both a software and hardware perspective.

Understand the parts you select. Rotate and place the parts to ease the wiring, with the most uniform and direct signal lengths. Use power planes, and make sure the decoupling and bulk capacitance is placed close to the component supply pins as possible. If not using power planes make sure to consider the current flows and sizes.

[glenn]

Posted on January 26, 2015 at 01:16

Thanks for the tips / suggestions Clive.