SDRAM init fails unless under a debugger

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SDRAM init fails unless under a debugger

461 Views
lpcware
NXP Employee
NXP Employee
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
Labels (1)
0 Kudos
3 Replies

401 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by suckfish on Fri Feb 15 13:19:19 MST 2013
Your yahoo post says you have problems with the EMC at higher clock rates.  Two things I found crucial to getting the EMC reliable at higher clock rates:

(1) Setting EMCDELAYCLK.  There doesn't seem to be much documentation of how to work out what to set this to.  I just used trial and error.

(2) I had to back off one of the timing parameters (I think DYNAMICDAL) from what the SDRAM datasheet indicates.  I found this by loosening all the timings and then tightening them up until I found what actually worked in real life.

Having done that, my 133MHz SDRAM chip seems perfectly happy at 160MHz.
0 Kudos

401 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mdittrich on Fri Feb 08 09:18:13 MST 2013
Thanks suckfish,

Ya, I posted further observations in my double post (I didn't realize this first post was moderated until I made the second...) here: http://www.lpcware.com/content/forum/sdram-init-fails-unless-under-debugger-0

Once I got by this issue, I hit another, detailed down in this post: http://tech.groups.yahoo.com/group/lpc2000/message/58391 (I have some circular references going on now :)

The TLDR is that you are absolutely right! I had neglected to update my EMC pinmux init routine to enable the EMC_CKEOUTx pin we decided to use on our design, which differed from the dev board.  I guess that issue could perceivably been influencing this one, though I don't know how.  I am fairly certain openocd does not touch the IO, it is really just "generic ARM" core stuff as far as I know.  The lpc specific stuff is only for flash programming, and that just sets up the params/payload in memory and calls into the IAP rom functions.  Everything else you need done is configurable via scripts.  I am not familiar with what the generic stuff does.

Thanks,
MD
0 Kudos

401 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by suckfish on Thu Feb 07 16:45:47 MST 2013
Does the debugger monitor I/O pins?  If so, it's presumably enabling the I/O pin input buffers.

Then if you've forgotten to do to set the SCU EZI bit for some pin, you might get your symptoms.  In particular check that you have all 4 clock pins configured correctly.
0 Kudos