AnsweredAssumed Answered

LPC4370 PLL Issues

Question asked by philipwilson on Nov 26, 2019
Latest reply on Dec 5, 2019 by philipwilson



We have a problem where the LPC4370 fails to configure the main PLL to 200MHz (or the internal clock) and the code does not run. 



We have been using the LPC4370 on a production board since 2014, it is manufactured in small batches since this time and this problem has just started.


The current silicon revision on these boards is D, we do not see this issue on all our boards with this rev D but it does vary. We have a significant number with this problem. We have not seen this problem on previous builds which use the C revision of Silicon. 


We have done our best to rule out the board assembly, we have a good level of certainty on the soldering as we have X-Rayed some of the boards, and applied another re-flow process to double check this. We are still open minded here but it feels more controller related.


We have determined that using freezer spray on the controller and repeatedly power cycling the software will boot up as we expect. We spray the top of the package. 


The system has some complexity to booting up and I will highlight what is working as we expect:

1. The power is applied and the built in bootloader (NXPs) loads our bootloader code into the controller from the SPFI memory device. (This always works)

2. Our bootloader runs and then loads in our main program image from SPFI Memory into the devices memory, we program this in memory above the current running bootloader and then jump the code running from the bootloader into the main application. To note the bootloader configures the system PLL to run at 204MHz, we can also see that this is correct with a spectrum analyzer and a monitor prob placed over the top of the controller (Our Bootloader always works as expected)

3. The main code runs from its start vector, the startup basically repeats a device clock start start up procedure in the same way that our bootloader runs thus resetting the PLL to 204MHz. (This mostly fails on this assembly build) It should be noted that we can see the 204MHz is running but the system is not running.


We found that if we edit out the clock setup in the main code all works as expected, this is because the 204MHz is running already when our custom bootloader hands over to the main code.


However, we have a sleep mode that shuts down the main PLL and then runs on internal RC. When this wakes up the system does not start up, again this is the same problem described above.


We have done some further investigation as follows:

 1. Ensured that we are following this latest User Guide suggestions. It was interesting to note that the example code we used from (2014) does not fully follow the user guide suggestion. We did adjust the code to bring this into alignment but this did not fix the problem outlined.

2. Debug using the 'Debugger' it should be noted that we are only debugging our main application here:

      a: Fails: If we run the debugger without breakpoints the code executes and then fails, limited information is available          on the failure when this happens the debugger loses control.

      b. Works (Partially): We determined that is we place a break point when the PLL register is set and then 'step over' it works every time. If we stop at the breakpoint and then execute the code (run) it fails every time. We drop into the fault handler mainly. The following code snip is where we have our break point:  LPC_CGU->PLL1_CTRL = PLLReg & ~(1 << 0); If we place the breakpoint at any other point the system will not run. It should be noted that we know using the spectrum analyzer that the 204MHz is up and running.


In summary:

We have tried various code changes without any impact the only reliable way is via the debug step though explained above. Freezer spray on the chip enables mostly the controllers to bootup if you are lucky.


Unfortunately, we can't ship a can of freezer spray with every unit as a fix.


Suggestions are very welcome.