Intermittent boot problems. Stuck in 64KB ROM code?

[lpcware]

Content originally posted in LPCWare by bazli on Fri Apr 29 06:20:52 MST 2016
Hi all,

We use the LPC1833 on our boards and most of the time it boots fine. On some boards though, we might see it fail 1/10 times.. When it fails, we connect debugger and it seems to be stuck in the 64KB rom area. Addresses we see are 0x10400fd8, 0x1040178a

Any ideas what might cause this?

[lpcware]

bump

[lpcware]

Content originally posted in LPCWare by bazli on Thu May 26 04:57:07 MST 2016
Hi,

we narrowed it down.. on boards that it fails, it's failing when we run CGU code to get it to 180MHz.. It seems to get to 96MHz reliably. Is it something that might be able to fix in code?

uint32_t    CGU_Init(void){

    CGU_EntityConnect(CGU_CLKSRC_IRC, CGU_BASE_M3);
    CGU_SetXTALOSC(12000000); //enable the external crystal = 12MHz
    CGU_EnableEntity(CGU_CLKSRC_XTAL_OSC, ENABLE);
    CGU_EntityConnect(CGU_CLKSRC_XTAL_OSC, CGU_CLKSRC_PLL1);
    CGU_SetPLL1(8);         // Set System Core Clock = 8 * 12MHz = 96MHz
    CGU_EnableEntity(CGU_CLKSRC_PLL1, ENABLE);
    CGU_EntityConnect(CGU_CLKSRC_PLL1, CGU_BASE_M3);
//    CGU_SetPLL1(15);        // Set System Core Clock = 15 * 12MHz = 180MHz <==== failing if we call this function..
    CGU_UpdateClock();
    return 0;
}

[lpcware]

Content originally posted in LPCWare by bavarian on Mon May 02 08:03:40 MST 2016
The addresses you see:
[list]
  [*]  0x10400fd8  - is somewhere in function calc_pll0  (calculate n/m parameters for PLL0)
  [*]  0x1040178a  - is somewhere in function tmhwBootRomCgu_SetConfig (divider and PLL settings)
[/list]

After these functions I expect that PLL0 is enabled with these settings. And that's where it seems to crash or hang up
Some wild guesses why it crashes:
[list]
  [*]  You somehow start sometimes with a USB bootmode configuration (because of somehow undefined boot pins) and the bootcode tries to switch on PLL0 with the external crystal as clock source. But in fact you don't have a crystal (or at least not a 12MHz).
  [*]  You have already code in your flash which puts the chip into a low power configuration. This could mean that the internal regulators are set to a lower level. This is set in the CREG power domain which survives a reset. Then the chip goes through the bootcode into the PLL0 setup and crashes because the regulators can't provide the necessary current for 96MHz PLL operation. In combination with the next point this could cause the problem.
  [*]  The power structure of your application is very weak and causes a voltage dip due to the power need of the PLL. This would fit to your observation that it is board related. Maybe you have inductors in the power supply lines?
[/list]

Hopefully this helps to find the problem,
NXP Support Team.

[lpcware]

Content originally posted in LPCWare by vtw.433e on Mon May 02 02:42:21 MST 2016
If you have any floating pins (boot, isp etc) then that would cause your intermittent problem. Have you bothered to investigate or are you over thinking it?

[lpcware]

Content originally posted in LPCWare by bazli on Mon May 02 02:37:59 MST 2016
won't those things cause it to not boot all the time? it only gets stuck 1 in10 times and even then only certain boards.. other boards don't have any issue at all.. that's why we suspect it's possibly some kind of tolerance issue?

[lpcware]

Content originally posted in LPCWare by vtw.433e on Fri Apr 29 08:32:41 MST 2016
Have you check the vector checksum?
Any of the other boot configuration pins?

AFAIK, If you are stuck in the boot rom, it is because the boot rom either cannot find a valid image to boot or you are holding ISP...

[lpcware]

Content originally posted in LPCWare by bazli on Fri Apr 29 07:07:51 MST 2016
Thanks for the reply :)
ISP pin  is already pulled up. Any other thing it could be?

[lpcware]

Content originally posted in LPCWare by vtw.433e on Fri Apr 29 06:25:22 MST 2016
Check the ISP pin - you cannot leave it floating.