SDRAM init fails unless under a debugger

[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,
MD

[lpcware]

Content originally posted in LPCWare by mdittrich on Mon Feb 04 09:31:44 MST 2013
Also, if a mod is watching http://www.lpcware.com/content/forum/sdram-init-fails-unless-under-debugger can be deleted, sorry for the double post.  When I made that first post I did not notice that it was flagged for moderation before making this second one.

[lpcware]

Content originally posted in LPCWare by mdittrich on Mon Feb 04 08:52:00 MST 2013
So I tried running spifi_init() before and after the SDRAM/EMC init routine thinking that might do something the LPC4350 bootloader was doing, but it did not change the behavior, no magic to be found.

I then found that reads from 0x28000000 were not failing (crashing everything) in my reset ISR, and they also did not fail immediately after SDRAM/EMC init, under debugger or not.  I found that the crash-on-read only happened after my uart init routine, specifically after a

<code>
LPC_RGU->RESET_CTRL1 = 1ul << 12;
</code>

for UART0.  Removing that line allows reads from 0x28000000 to not crash things.  All previous tests from my first post were ran after uart init.  I had code that polled LPC_RGU->RESET_ACTIVE_STATUS1 & (0x1ul << 12) after the RESET_CTRL1 write, I had code that just waited 100us after it, both would still crash upon SDRAM reads (though UART0 has always worked fine, even without the RGU reset).

I might be doing something wrong, but I didn't find anything in the user manual / errata that warns against something like this.  The errata has an IRC calibration issue when at extreme temps (room temp for these tests), and the user manuals says the RGU runs off the IRC.  I'm guessing some of my CGU init code might be messing with things?

I was never able to determine the failure mode, my hardfault handler would reliably fire (under debugging or not (kick characters out UART0 in a while(1) when not debugging)) with a precise data bus fault when reading from spifi/0x14000000 before doing a spifi_init(), but I do not get characters for the "0x28000000 read after UART0 RGU reset" case and the failure does not happen when debugging.

I'm curious what I am doing wrong, but will just be avoiding the RGU for the time being (curiously none of the example code in git repo ever uses an RGU reset that I can find).

Thanks,
MD