4
\$\begingroup\$

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

\$\endgroup\$

3 Answers 3

Reset to default
3
\$\begingroup\$

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.

\$\endgroup\$
2
  • \$\begingroup\$ Thanks David. I was trying to squeeze this design onto 4 layers but trying to cut costs has its disadvantages. I am going to do the following in a redesign: 6 layers (shorter traces), 22 Ohm termination on data lines, add RAM decoupling caps, reduce the number of vias on the lines. I'm unsure if I need termination resistors or not on the address lines and control signals, as I've not seen these on the datasheet. Also why would I want a cap near signal trace vias? I'm a 'home grown' engineer and so have no signal integrity training! \$\endgroup\$
    – James
    Feb 18, 2012 at 17:14
  • \$\begingroup\$ @James The key term you are missing is "Signal Return Path". A signal doesn't just go one way, it has to return; usually using the power or ground plane. Managing this return path is key to signal integrity and EMI (both unintentional RF transmission and RF reception). This is a huge subject, but here is some light reading: ti.com/lit/an/scaa082/scaa082.pdf \$\endgroup\$
    – user3624
    Feb 18, 2012 at 18:22
3
\$\begingroup\$

Smells like a data-dependent problem. You may have some unfortunate coupling between some of the data and/or address lines such that the right pattern causes a failure somewhere.

Try slowing down the clock. How the symptom changes or not may give some clues. If there is crosstalk between some of the address and data lines, this should make the problem go away because transfers are done after everything eventually settles. If the problem is noise getting onto the clock line, then this probably won't change anything.

Look at some of the signals with a scope and see how clean they look. Did you put resistors in series with the lines to match the trace impedance better and reduce ringing? Make sure to check the clock line too, not just a few data lines. Also verify you really have the setup and hold times the chip needs.

Remember that apparent proper operation is not proof of correct operation, only of being lucky.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Hi Olin, It just seems really weird that the same problem happens exactly the same way each time. I have not impedance matched the transmission lines. I have clocked the chip down to 12Mhz and the SDRAM EMC interface to 6Mhz and the exact same problem persists. It is really odd that normal data access is not a problem, but running the applicaiton results in errors. I may just redesign the circuit on 6 layers, impendance match every line and hope for the best! \$\endgroup\$
    – James
    Feb 15, 2012 at 17:34
2
\$\begingroup\$

What memory tests are you running? In addition to the classics fill it with 0's and F's and A's and 5's and walking ones and all that, and the address to do an address bit test. My favorite is a pseudo random test. take an lfsr (very easy to code, deterministic and repeatable and is "random enough"), seed it, fill memory with random numbers (dont skip any or stop short, beginning to end one pass one seed at the start, insure/choose the lfsr does not repeat within the space you are using it), seed it and read back. seed it, fill memory with the inverted values from the randomizer, seed it check. Change the seed and repeat. I tend to let a test like this run for a while. It very quickly finds address bit problems and data line problems and many of the normal problems faster than the traditional tests.

What happens if you slow the clock(s) down and run slower, does it change?

If it is not hardware then focus on software, what is different between the dev board and your board? break the application down into pieces and see if any of it runs or if it fails no matter how much you trim it down.

\$\endgroup\$
3
  • \$\begingroup\$ ahh, sdram, is your refresh working? when doing a randomizer test described above, add a test that fills memory, waits many seconds or minutes then reads back. Slow is as hard to pass as fast. \$\endgroup\$
    – old_timer
    Feb 16, 2012 at 21:46
  • \$\begingroup\$ Thank you. I shall create these tests as you suggest and see if I can find out the problem... I will also try your suggestion of waiting a few minutes before reading back the data to check the refresh, a very good idea. I hadn't thought of that! \$\endgroup\$
    – James
    Feb 18, 2012 at 17:13
  • \$\begingroup\$ same deal with eeprom and flash, but you have to wait longer. Had an eeprom that took weeks for a bit or two to fade/change state. \$\endgroup\$
    – old_timer
    Feb 18, 2012 at 23:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.