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 Fri Feb 01 11:22:33 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 (fill the entire range with an incrementing value, then test the entire range for the corresponding incrementing value) 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.  I found http://www.lpcware.com/content/forum/nxp-lpx1857-emc-sdram-read-failure#comment-3175 which implies this should not happen, assuming the 1800's and 4300's are similar in this regard.  Since the debugger is not running I don't really know whats going on.  I am not executing any code from SDRAM, just dereferencing a uint32_t* to 0x28000000.

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 fine but the mem test will fail. Cycling power to the board with the debugger running also yields failure, until a "soft_rest_halt" (which does NOT assert TRST or SRST) is reissued.  A restart using SRST via my external reset chip behaves the same way.

I'm running the EMC at 60MHz, core at 120. I have not really played with slower/faster since it works very repeatably under the debugger.  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 found in lpc32xx_emc.c) without any changes.

It 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/bootloader do anything different with a debugger connected?

Enabling "debug_level 3" in openocd shows that a "soft_reset_halt" does some writing to the 0xe0001020-0xe0001060 and 0xe0002000-0xe0002024 ranges that a "reset" does not.  I understand these are the cortex-m "DWT" and "FPB" registers (which make sense).  There is a lot more debug output that I am not looking forward to understanding...

Thanks in advance for any advice,