LPC4350 Not Resetting Properly After Initial Power On Reset

[lpcware]

Content originally posted in LPCWare by gregd on Thu Oct 18 07:39:23 MST 2012
We have a new board that we have designed based around the LPC4350.  We are booting from external 32 bit Static Flash memory.  The board works perfectly every time when debugging through the IAR EWARM along with a Segger J-Trace J-Tag module.  With the J-Trace removed, the board boots normally when first powered and works fine most all the time.  Once the board is running, if you simply ground the Reset input to the LPC4350, it will never reset and start running from the external flash like it does on the initial power up.  Any ideas on what would cause this?

Thanks,
Greg Dunn

[lpcware]

Content originally posted in LPCWare by gregd on Fri Oct 26 11:56:04 MST 2012
I think I finally figured this one out.  On boot up, only A0..A13 are initialized as address lines.  A14..A23 only have pull-downs turned on which look like they only sink about 60 uA at 3.3 volts.  I am using SN74ALVTH162245 buffers in the memory circuit which include the bus hold feature.  300 uA is required to pull an input line low when it's high.  I found that A16 was stuck high after I applied the manual reset.  This was causing the wrong address to be read from the flash.

Thank you very much for your help in solving this problem.

Greg

[lpcware]

Content originally posted in LPCWare by gregd on Thu Oct 25 09:10:16 MST 2012
I am not changing anything related to sleep and power-down modes yet. 
The IAR IDE shows the following value during normal application execution:
PMC_PD0_SLEEP0_MODE = 0x003FFF7F

I am updating a few CREG values however.  Here are my settings while the application is running:
CREG_CREG0       = 0x00000F1C
CREG_M4MEMMAP    = 0x1C000000
CREG_CREG1       = 0xFFE44A08
CREG_CREG2       = 0x00000000
CREG_CREG3       = 0x00000001
CREG_CREG4       = 0x00000000
CREG_CREG5       = 0x40000670
CREG_DMAMUX      = 0x00000000
CREG_ETBCFG      = 0x00000001
CREG_CREG6       = 0x00030000
CREG_M4TXEVENT   = 0x00000000
CREG_CHIPID      = 0x5906002B
CREG_M0TXEVENT   = 0x00000000
CREG_M0APPMEMMAP = 0x10080000


I think I did discover another issue while investigating my reset problem.  It is a problem either with the NXP documentation, J-Link firmware or IAR EWARM.  When I open the CCU1 register view and then try to step through the application, I start getting errors and have to close the IDE.  I narrowed it down to errors when accessing the following two registers:  CCU1_CLK_USB0_CFG (0x40051800) and CCU1_CLK_USB0_STAT (0x40051804).  If I comment these registers out of the iolpc4350_m4.ddf file then things work ok.  These addresses seem to be correct according the users guide but if I access them through the JLink command line, IAR EWARM, or Keil UVision, I start getting errors and have to restart the debug session.  I'm not sure if this has anything at all to do with my reset problem but I thought I would report the issue so it can be corrected.  I have duplicated the issue using the Hitex A4 board and the simple Gpio_LedBlinky example in the lpc43xx library files so it doesn't seem to be related to our board design.

Thanks,
Greg Dunn

[lpcware]

Content originally posted in LPCWare by bavarian on Thu Oct 25 04:49:33 MST 2012
Hello Greg,

one reason for the problem you see could be changes in the CREG registers. A few of them survive a reset, but not a power cycle.
Maybe you used some code by accident (or by purpose) which changes these registers in such a way that the bootloader can't do its job properly.
Example: you sent the device into deep sleep or power-down with a different power-down word than specified in the user manual. The register PD0_SLEEP0_MODE contains bits for test purposes, they could influence the startup behaviour.

Best regards,
NXP Technical Support Team

[lpcware]

Content originally posted in LPCWare by gregd on Wed Oct 24 15:54:29 MST 2012
It is my understanding that the boot selection pins are sampled after the reset line goes high and the ROM boot code is actually running.  Is this correct?  I would not think that being in the middle of a read of the flash when the reset line goes low would have an impact on this.  The reset line is also connected to the reset of the flash so it should reset the flash chip also.  Looking at it on the scope while reset is low and also as it goes high, all of the memory control lines and boot selection pins appear to be correct.  I actually see CS0 and OE pulse low four different times - apparently as the initial SP and execution address are read by the boot ROM.  It looks like when the jump to the execution point is attempted is where the failure occurs.  You are probably right that a failure is occurring during these flash reads. 

Please note that we had already added 7.5K pull up resistors on EMC_CS_2, EMC_CS_3 & EMC_DYCS0 to make sure these lines are high during the ROM boot process.  We are not using EMC_CS1.  We had to do this early on to make the board boot at all because the SRAM was been selected during boot up.  I have confirmed that they stay high during the manual reset also so they should not be causing the problem.  I will also add a pull-up on L_CS_0 to see if it makes any difference but I don’t think it should as the LPC4350 takes control of it during the boot process.  I do see that L_CS_0 is low during boot-up from cold start and also when manually resetting.  Maybe the flash chip has a problem when you have CS low during reset.  Anyway, I will give it a try.

Thanks,
Greg

[lpcware]

Content originally posted in LPCWare by nxp21346 on Wed Oct 24 09:17:34 MST 2012
The Boot Process flowchart in the Boot ROM section of the User's Manual describes all the circumstances that result in a failed boot. Maybe the part is either trying to boot in the wrong mode, (due to the pullups being affected by the flash part being in the middle of a read) or maybe it is failing to read the flash properly after a reset. My first reaction would be to suggest resetting the flash with the MCU but it sounds like you have already done that. Can you try a pullup on the flash CS and also if you are using buffers to make sure they are inactive during reset?

[lpcware]

Content originally posted in LPCWare by gregd on Mon Oct 22 16:48:57 MST 2012
Thanks for you help Phil!

I checked all of the boot source inputs.  There were some issues with them.  We had 10K pull up/dn resistors originally.  We are using memory buffer/drivers with bus hold features.  They required at least 300 uA to pull a low input high.  We had to lower the 10K resistors to 3.3K to provide the needed current.  The boot select inputs seem to be just fine now.  The ISP boot (P2_7) was also in the same category, we lowered the value of the pull-up to 3.3K and it looks fine on the scope now.  The reset line is feeding the processor and also the external NOR flash memory that I am trying to boot from.  I thought possibly the slow rise time of the reset line may be allowing the processor to exit reset and start running before the external memory reset was released due to threshold differences.  I removed most of the capacitance from the reset line to speed up the rise time.  This didn't solve the problem either.  I have looked at most all of the lines on the scope that I can think of during the first time power start-up (which works fine) and while giving a manual reset without cycling power.  Everything looks good as far as I can tell. 

The board boots fine with a power cycle but doesn't with a manual reset.  When I apply a manual reset, I can see that CS0 and OE are going active now like they should, but they stop after two quick pulses.  I also see P1_1 start toggling at 1 Hz rate indicating boot failure.  I am assuming that it is trying to boot from EMC CS0 since I see the pulses.  I'm not certain if its attempting a 32 bit boot or not.  Seems like it must be getting an error reading from the flash.  I am going to try and disconnect the reset input completely from the Flash memory and just leave it high for a test.  Any other suggestions would be very much appreciated.

Thanks,
Greg      

[lpcware]

Content originally posted in LPCWare by PhilYoung on Sat Oct 20 15:46:01 MST 2012
I saw a similar problem using the watchdog, it seems that the internal pullup on the boot pin (P2_7) is too weak so when the external bus is running it is often sampled low on reset and the device enters the flash programmer.
The solution was to add an external 10K pullup on P2_7.