AnsweredAssumed Answered

KBOOT Version 2.0.0 with SDK 2.3.1 on FRDM-K22F Eval board

Question asked by terryabramson on Jul 5, 2018
Latest reply on Jul 9, 2018 by terryabramson

I have been experimenting with changing clock modes using SDK demo applications that I have adapted to the KBOOT flash resident bootloader (Version 2.0.0). In it's simplest form, I used the K22FN512xxx12_application_0xA000.icf linker file, startup.c, startup.h, crt0.s, from the led_demo project of the KBOOT .zip in order to adapt the gpio_led_output project from SDK 2.3.1. In my current application changes to the bootloader are not possible, any workaround must be in the application code.

 

With no other modifications to the code I am able to successfully bootload the application most of the time. Frequently enough to be a problem, the application doesn't boot. And using blhost the FRDM board is not communicable, i.e. not in KBOOT. I can reconnect with KBOOT after a reset. The application will also launch after the default 5 second timeout after 1 to Many resets. When the application fails to boot correctly I use the debugger and IAR's "Attach to Running Target" to see what state the uC is in.  I am seeing the clock initialization of the application fail and spin here:

while((MCG->S & (MCG_S_IREFST_MASK | MCG_S_CLKST_MASK)) != (MCG_S_IREFST(kMCG_FllSrcExternal) | MCG_S_CLKST(kMCG_ClkOutStatExt)))
{
}

By looking at the MCG registers I can confirm that the IREFST bit in MCG_S is not changing as expected. And I can confirm that I have not seen a hang elsewhere.

 

I have a couple observations that I made based on some information gleaned from the discussion here and here.

  1. An Errata exists on the transition from FBE/FEE to FBI/FEI
  2. An Errata exists on the FLL External <-> FLL Internal transition
  3. KBOOT 2.0.0 still does not return the clock to a proper POR state
    1. MCG_C2 register has value of 0x80 from KBOOT but has value of 0xC0 from POR
    2. MCG_C4 register has value of 0x20 from KBOOT but has value of 0x10 from POR
  4. The transition flow is not correct to the documentation in the K22FN512 reference manual

 

My comments on the aforementioned is as follows:

  1. e7735 is specifically the transition from FBE/FEE to FBI/FEI not a transition from FEI to anything else. Further it is about setting MCG_S[IREFST] to 1, not clearing it to 0.
  2. A workaround for e7993 is already implemented in the clock driver of the SDK.
  3. I have attempted to set these values manually to the ones I have seen through the debugger immediately after a POR. And the issue persists.
  4. I have tried replacing the BOARD_BootClockHSRUN() call with the CLOCK_SetMcgConfig call using the same config as is used inside the BOARD_BootClockHSRUN function. Doing this changes causes the hang to always happen. The application also does still run correctly most of the time, and the clock is still in FEI mode as expected from a POR.

 

I have also tried replacing the while loop with and if statement and returns kStatus_Fail in order for me to retry, setting the clocks, this just causes a hang at the external loop.

 

Interestingly, using the pee_blpi demo from the SDK without adapting, I can make the transition from FEI to FBE just fine, and have not seen the issue recreated, even when attempting to re-create the issue. Further to this, taking the application I did adapt for bootloading and solely running that on the eval board without KBOOT I have also yet to see it fail. However as soon as I start playing with the clocks before the BOARD_BootClockHSRUN call I can cause it to fail, but only in the adapted application.

 

Is there a workaround to this?

Outcomes