I have been having intermittent problems with an LPC2368 design in that the
processor sometimes fails to start up when power is applied. There is an
ethernet MAC on the same power plane that does start up (indicated by speed
& activity LEDs), but on the 2368 my code does not run, and attempting to
connect via JTAG fails.
I have observed this on several different units, it is not particular to a
specific unit. It only seems to affect about 5% of the builds. All chips are
revision B.
Does anyone have any idea what sort of power anomaly at start-up would cause the
2368 to not boot properly? Or any suggestions for determining what state the
processor is in when it doesn't boot my code or allow JTAG connection?
- Joe
LPC2368 does not start up (intermittent)
Started by ●October 19, 2011
Reply by ●October 19, 20112011-10-19
In my experience this is more likely a SW bug due to using some
uninitialized variable or not setting up the HW properly than a HW bug.
Good examples are setting the PLL incorrectly, or enabling the CPU to run
from a high speed clock without enabling the flash accelerator with the
correct timings.
It depends on what you did with the exception handlers, but I've seen that
it is not possible to gain access with the debugger if the CPU enters a
fault handler which simply branches to itself, or kills the clock.
I don't use the 2368 but have seen similar behaviour on the LPC11xx, and
LPC17xx devices so I'm speculating here but a good test for the HW is to
boot the device so that it enters the on chip programmer code then connect
with the debugger to regain control. If you can do this reliably then it's
not a HW fault, I guess it depends on how reliably the devices normally
boot.
Also a good indicator may be if the device struggles to boot after power
down, but once running can be reset reliably, this would be more likely if
something was used before initializing as presumably once the code runs it
is not a problem and would be unlikely to affect the next boot after reset
so long as power was not removed.
Regards
Phil.
uninitialized variable or not setting up the HW properly than a HW bug.
Good examples are setting the PLL incorrectly, or enabling the CPU to run
from a high speed clock without enabling the flash accelerator with the
correct timings.
It depends on what you did with the exception handlers, but I've seen that
it is not possible to gain access with the debugger if the CPU enters a
fault handler which simply branches to itself, or kills the clock.
I don't use the 2368 but have seen similar behaviour on the LPC11xx, and
LPC17xx devices so I'm speculating here but a good test for the HW is to
boot the device so that it enters the on chip programmer code then connect
with the debugger to regain control. If you can do this reliably then it's
not a HW fault, I guess it depends on how reliably the devices normally
boot.
Also a good indicator may be if the device struggles to boot after power
down, but once running can be reset reliably, this would be more likely if
something was used before initializing as presumably once the code runs it
is not a problem and would be unlikely to affect the next boot after reset
so long as power was not removed.
Regards
Phil.
Reply by ●October 24, 20112011-10-24
--- In l..., "Phil Young" wrote:
>
> In my experience this is more likely a SW bug due to using some
> uninitialized variable or not setting up the HW properly than a HW
> bug.
To expand, the device has a Pover-Over-Ethernet input and an aux power input. Both the POE circuit and the aux power input feed a 5V dc-dc converter which feeds a 3.3v regulator for the 2368 and National 83848 PHY.
The boot-up problem observed only happens when using the POE supply.
I changed my bootloader code so that the very first thing that happens is to turn on an LED. The LED does not come on.
Next, I tried booting the internal ISP code (i.e power up with p2.10 low). And I see the same thing. The PHY's LEDs light up, but the 2368 appears to be dead. (I can not connect via JTAG.)
I have only started to see this problem recently. Date codes of the chips where I have seen this problem are 0740B and 0741B. Never seen this on a rev A chip.
I was just made aware of errata on VBAT. Says you can not leave VBAT floating, or else boot-up problems may happen. We have always connected VBAT to ground, although it is now suggested that VBAT be tied to VDD when not used. I'll switch this over on a couple problem units to see if the problem goes away.
>
> In my experience this is more likely a SW bug due to using some
> uninitialized variable or not setting up the HW properly than a HW
> bug.
To expand, the device has a Pover-Over-Ethernet input and an aux power input. Both the POE circuit and the aux power input feed a 5V dc-dc converter which feeds a 3.3v regulator for the 2368 and National 83848 PHY.
The boot-up problem observed only happens when using the POE supply.
I changed my bootloader code so that the very first thing that happens is to turn on an LED. The LED does not come on.
Next, I tried booting the internal ISP code (i.e power up with p2.10 low). And I see the same thing. The PHY's LEDs light up, but the 2368 appears to be dead. (I can not connect via JTAG.)
I have only started to see this problem recently. Date codes of the chips where I have seen this problem are 0740B and 0741B. Never seen this on a rev A chip.
I was just made aware of errata on VBAT. Says you can not leave VBAT floating, or else boot-up problems may happen. We have always connected VBAT to ground, although it is now suggested that VBAT be tied to VDD when not used. I'll switch this over on a couple problem units to see if the problem goes away.
Reply by ●November 9, 20112011-11-09
I'm thinking this is a Power-On-Reset issue. I do not have a reset
controller on the board. When the 2368 doesn't boot at power on, toggling
external reset always makes it come to life.
There was a major layout change to this board (went from parts on both sides to parts on one side), which may explain why we are seeing the problem much more now. There were 6 problem boards of 100 with the new layout as opposed to about 2/200 problem boards with the previous layout.
There was a major layout change to this board (went from parts on both sides to parts on one side), which may explain why we are seeing the problem much more now. There were 6 problem boards of 100 with the new layout as opposed to about 2/200 problem boards with the previous layout.
Reply by ●November 10, 20112011-11-10
Have you ruled out your clock source yet? Maybe do a test using an internal
clock to see if it starts up. If it does work you might have to adjust your XTAL
load capacitance.
Reply by ●November 10, 20112011-11-10
--- In l..., "jhvdb" wrote:
> Have you ruled out your clock source yet? Maybe do a test
> using an internal clock to see if it starts up. If it does
> work you might have to adjust your XTAL load capacitance.
I think so. I changed the code so an LED is turned on before attempting to start up the PLL off the external crystal. The LED would never come on. Could a faulty start-up of the PLL affect GPIO output turning the LED off???
> Have you ruled out your clock source yet? Maybe do a test
> using an internal clock to see if it starts up. If it does
> work you might have to adjust your XTAL load capacitance.
I think so. I changed the code so an LED is turned on before attempting to start up the PLL off the external crystal. The LED would never come on. Could a faulty start-up of the PLL affect GPIO output turning the LED off???
Reply by ●November 10, 20112011-11-10
