lpcware

PLL1: permanent chip lock up / danger of destruction?

Discussion created by lpcware Employee on Jun 15, 2016
Content originally posted in LPCWare by mch0 on Tue Aug 19 03:36:36 MST 2014
Hello,

for a custom board I have to fiddle with the PLL1 probably more than usual.
During some tests I encountered the following situation:

The target 4370 did not react any more to the JTAG debugger and it became also hot to a degree that I feared thermal destruction.
Since the "offending" program was in SPIFI flash and boot mode was also SPIFI it was not possible to resolve the problem with the JTAG debugger alone.
The only solution so far was to alter the boot mode (e.g. USB) so that the chip would not execute the "bad" program before the JTAG debugger could connect.

Now this raises the somewhat scary question whether the chip can really be destroyed by some erroneous PLL operation in the field.
It also raises (again) questions about the PLL operation.

What did I try:
I wanted to reprogram the PLL1 to arbitrary frequencies by the following procedure:

a) select BYPASS=1 and FBSEL=0
b) reprogram the PLL loop parameters
c) wait for LOCK
d) set BYPASS=0

The idea was to let the PLL lock while the CPU runs from the safe slow clock.
According to Fig. 35 in the UM the loop should have been closed.
However I observed that the PLL would not lock, at least not in the STAT registers as long as BYPASS=1.

Then I tried another approach by directly ramping up the PLL to the target frequency (no BYPASS), but with the postscaler set to 2.
By accident (my error) I set the CCO to generate 400 MHz which is well out of range, even if the output to the base clock would have been in range (200 MHz).

At that point the chip became unusable and increasingly hot as described.
I'd say the CCO ran at its design limit in the wild.

Now I know that I made a programming error but it opened up the possibility of dying chips in the field just by some accident.

My first question:
Does this danger of thermal overload exist?

My second question:
Is my observation correct that the PLL will not lock or not indicate a lock in the STAT register with BYPASS=1, even for perfectly "normal" loop settings (nsel, msel)? I did not find an offending remark in the UM so far.

Regards,

Mike

Outcomes