LPC4370 PLL Issues

[philipwilson]

Hi,

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. 

Background:

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.

Thanks,

Phil

[philipwilson]

Vicente,

Thanks for the response.

We don't quickly have the ability to change the device with another, however I suspect that changing the device will yield an improved performance. Below is a further insight into the differences we have seen and how we have eased the problem.

 - It turns out that the main reason we did not get a reliable boot up of our main image was found to be linked to the amount of time it is required for the wait after enabling the 32.768KHz. The user guide recommends a 2-second delay before the RTC registers are setup, we have found that we need a much greater period of time before we configure the RTC. We have seen times from 2s to ~8s this was determined by adjusting the time before the RTC was setup and trying across a number of boards.  We have not implemented code to check the downcounters as a suggestion or experimented with this, instead, we have delayed the RTC on powerup. This does seem to fix the issue at least on the controllers we have here. Basically setting the RTC to soon holts the processor as per the datasheet/user guide suggest may happen.

- We are not sure why this would be the case, if anyone knows please let us know or have an example of the down counter technique.

- In terms of the freezer spray, we broadly determined that with the cold spray on the crystal without the long delay would enable the bootup of the boards. I suspect that this was due to the crystal starting up quicker.

- Additionally, we have noticed that the output from the XTAL controller pins is higher for this revision of silicon than the previous batch we had. In terms of the 32KHz crystal, we are 100mV greater, it was also noticed that the higher frequency crystal, 12MHz in our case is also a higher voltage. (It should be noted that we only have a 10X scope probe to measure this so it is loading the crystal more)

-  We have also noticed that the 12MHz Crystal / PLL takes longer before it locks as compared to other boards. This is an observation rather than measured.

- In terms of why the debugger works on one revision and not the other I am not sure, I suspect some difference in silicon could be the reason. I also think that the debugger may access the RTC register before the crystal is ready and thus holt the cpu as per the issue above.

The above is a summary of several weeks of work late nights of stripping back the layers. We don't have the answer to why the above is really happening we just know that we have a workaround, any further insight would be helpful.

Thanks in advance at least we don't need to ship freezer spray and an engineer now with every unit.

[vicentegomez]

Hi

What happened if you put a "failed device " on a known good board, the failure follows the board or the device?

Please let me know your comments