Custom bootloader, PLL issue when jumping to user application

[adarrow]

We are using a custom board with a Kinetis K64. We have a custom bootloader which is a Processor Expert based project, and some of it is based on the Kinetis Bootloader. We also have a custom application which is a Processor Expert based project and uses MQX RTOS for KSDK 1.3.0.

The problem we are having is sometimes when we jump from the bootloader over to the application, we get stuck in a PLL loop in the startup code of the application. Here is the line of code that the application gets stuck on:

while((MCG->S & MCG_S_LOCK0_MASK) == 0x00U) { /* Wait until PLL is locked*/

This line of code is in the following file:

/OurProject/SDK/platform/devices/MK64F12/startup/system_MK64F12.c

Sometimes everything works fine and we get out of this loop and the application launches correctly. Other times it just sits there forever.

If we just flash in the application and run it without bootloader, the application starts every single time with no problems, so there is something wrong with our handoff from bootloader to app.

Does anyone have any idea what might be causing this problem?

[gabrielharrison]

Hi,

We have the same issue although it is infrequent. I initially thought it was purely an issue when using the debugger.

I'm currently looking at resetting the MGC back to the default 21MHz before exiting the bootloader because we need the app to set up the clocks when debugging without the BL having run.

Gabriel

[mjbcswitzerland]

Hi

This seems to be a typical problem with the clock configuration code which assumes that it is starting from the reset state and doesn't handle situations where the clock has already been used (It is one of the most common difficulties running MQX example based code with boot loaders, based on supporting a number of such projects used with the uTasker boot loaders).

The simplest solution is to have the boot loader configure the clock as required later by the application and then the initialisation can just be skipped in the application part.

Regards

Mark

[adarrow]

Thanks for the info Mark. We have considered this approach but our products go into the field for 10-15 years (and we sell thousands of them) with a ROM bootloader and we don't want to be locked into a specific clock configuration in case we need to change the clock configuration at the application level at some point in the future. Ideally our bootloader would put the clock configuration into a reset state so we have that flexibility built in since field updates to the bootloader are basically impossible in our situation.

All that being said, it sounds like we need to spend some time getting things back to a reset state when we exit the bootloader and jump to the app?

[mjbcswitzerland]

Andrew

There are some advantages of resetting things to reset state (eg. after using USB in the loader to avoid possible pending interrupts when the application starts) but I have never had to reset the clock. The uTasker (Kinetis) clock initialisation has no problems moving from boot to application settings (with or without different speeds) so the issues are really due to the clock initialisation code which tends to be present in the MQX demos.

Also there is no problem/risk with skipping the clock initialisation in your "first" application since as long as you solve this in subsequent applications (that need a different speed) there is no problem for the future.

I also have hundreds of thousands of devices (Coldfire/Kinetis/LPC2xxx/LPC17XX and other non NXP processors) in the field, some of which have been updated a number of times during over ten years and more, so your situation or requirement is not new - it is probably just the present clock initialisation routines that need to be worked out since it is not normally something that causes any concern.

Regards

Mark

[adarrow]

Thanks for the real life examples Mark, perhaps we can rely on just the bootloader configuring the clock. I'll present that to the rest of the team, although I'm sure they will still want to get to the bottom of the issue.

One other concern about not doing the clock configuration in the application was not being able to compile and debug the application without the bootloader present, but I suppose that could be worked around by simply having separate build configurations for the app, one with clock configuration and one without.