Electronic – SDRAM issue – LPC1788

memorymicrocontrollerroutingsdram

I have been using an NXP LPC1788 dev board which I have developed my application on (.NET Microframework Cortex-M3 Port).
Everything was well and good on this board, I had no issues with RAM or otherwise, and so I was ready to begin development of my production board.

I created a new board with the same RAM and processor, and I took the binary from the dev board and put it on the new board and I am getting problems when running from SDRAM. Not the usual where there is no connection, nor is there an intermittant fault… I can run a memory test (write to the entire SDRAM block in 32bits, 16bits, 8bits and read back the correct data multiple times).

However when I try to run my application I get really odd problems with RAM either getting overwritten, or not written at all. This is only when running the application which is perfect on the dev board. It is not intermittant, it does the same thing every time. Because of this I assume it is not my routing that is causing me issues (because my memory check passes).

Is there some odd feature of the LPC1788 EMC (ARM PrimeCellâ„¢ MultiPort Memory Controller) that I am not aware of that could be causing buffering issues or read-ahead problems? If anyone with experience with this could point me in the right direction, or help me write a better memory test to test for these odd conditions would be very helpful…

I have attached a picture of the routing, which although is not optimal (I have only 4 layers, 2 signal, 2 power plane) does allow the RAM to function and I can read from the device.

enter image description here

Best Answer

Long, parallel traces. No signal termination. No decoupling caps on the RAM. Signal traces going from top to bottom layer without a cap near by. Traces with long, unterminated, stubs. Some signals going through 5 vias. And possibly not enough vias on the power/gnd pins of the BGA (but it's hard to tell from your picture).

Any of these could cause memory problems, and some at any speed. Carefully probe your clocks at the destination with a high speed o-scope (350 MHz or greater) and show us what you see. Odds are that you have a problem with signal integrity.