lpcware

SDRAM init fails unless under a debugger

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by lpcware
Content originally posted in LPCWare by mdittrich on Thu Jan 31 17:50:55 MST 2013
I started development on an MCB4350 and had the SDRAM working fine.

I am now trying to get my LPC4337 based board up and running, and I am encountering SDRAM/EMC failures when not running under a debugger (openocd (with or without gdb connected)).  The SDRAM on this board is smaller than the MCB4350 board, but otherwise the init code is the same, still a single 32b IC.

If I run a "soft_reset_halt" via openocd, a quicky memory test passes just fine. If I don't run the debugger (but it's still physically connected (or not)), everything locks up upon the first read from the SDRAM area.

After a "reset" via openocd (configured for 20ms of both TRST and SRST (and then oddly a ~24ms release of no resets, followed by ~72ms of just SRST...)), the code restarts and the mem test fails.  Cycling power to the board with the debugger running also yields failure, until a "soft_rest_halt" (which does assert TRST or SRST) is reissued.

I'm running the EMC at 60MHz, core at 120.  I have verified that the SDRAM init code timing is the same under both conditions (via GPIO toggles): init pins, init EMC, and SDRAM NOP command issued within 1.5ms of the release of reset (starting from boot out of flash, reset held low for ~150ms by external reset chip).  Then 100us pause, issue precharge all, set LPC_EMC->DYNAMICREFRESH, wait 128ms (2 64ms refresh periods), issue MODE, do the "dummy write" to set MODE, issue NORMAL, enable buffers in LPC_EMC->DYNAMICCONFIG0, and the whole process is done after ~130ms.  I have sprinkled 10-100us delays between the steps (as in lpc32xx_emc.c) without any changes.

Its seems there is some magic in the debugger that is not in my code. Before I go off trying to find that magic, has anyone else encountered anything like this? Is there any magic in the 4350 ROM bootloader (when booting from SPIFI) that might be covering up some bugs in my init code?  Are there any interesting register values to dump out the serial port under both conditions?  I am looking for some ARM core or chip wide registers that openocd might know about and have the chance of affecting.  Does the silicon do anything different with a debugger connected?

I can't ship a whole development PC with every one of my products, so my current workaround is not feasible :)

Thanks in advance for any advice,
MD

Outcomes