Clock synchronization issue with KBOOT bootloader and MCG mode switching with FRDM-K22F

[kevinlfw]

Note: This is a post carried over from here: https://community.freescale.com/docs/DOC-256669?et=watches.email.document_comment#comment-34974

I was unable to post an attachment when commenting on the thread, so to make sure the file is always available I've created another post that the source code attached and the instructions below.

I jerry-rigged the led_demo project to recreate the issue.  The (my) idea was to just add the KSDK 1.3.0 Platform code (for the FRDM-K22F) to the KBOOT package and call the default "hardware_init()" found in all of the KSDK examples.  The issue is recreated recreated if you follow these steps with JLink OpenSDA V2.1 driver installed on FRDM-K22F development board:

1. Install KBOOT 1.2 package (mine was extracted to a directory named "FSL_Kinetis_Bootloader_1_2_0")

2. Open the IAR project, "%INSTALL_DIRECTORY\FSL_Kinetis_Bootloader_1_2_0\targets\MK22F51212\bootloader.eww"

3. Make the freedom_bootloader - Debug project the active project. (Right-click "freedom_bootloader - Debug" > Set as Active..)

4.  Go to aforementioned project's options. (Highlight "freedom_bootloader - Debug" and press Alt + F7)

5. Change Debugger > Driver, to "J-Link/J-Trace" and click "OK"

6. Press Ctrl+D to Download & Debug the bootloader and press F5 to run the application when it breaks on main

7. You can now stop the debugging the bootloader by exiting IAR

Download user application to FRDM-K22F

1. Download source code in the attached zip file.

2. Unzip the contents to a directory

3. Open "led_demo.eww"

4. Build the "ksdk_platform_lib" project

5. Build the "led_demo_FRDM-K22F" project (note that the linker file used is in the same location as the led_demo.eww file, which uses places application at offset 0xA000)

6. Make sure "led_demo_FRDM-K22F" is the active project

7. Download & Debug the application, press F5 to run the application after it breaks on main()

8. At this point the RGB LED should be changing, just like it does in the normal led_demo (except blinking at a faster rate).  Don't stop the debugging at this point, continue below.

Make it happen

1. Now, press the "Reset" button on the FRDM-K22F board

2. Wait ~5 seconds (bootloader is waiting for peripheral activity)

3. If the user application ends up running, the debugger will break on main(). Press F5 to continue running.  Then repeat step 1 & 2 until you get the symptoms found below.

4. If the user application doesn't appear to be running, break via the debugger and observe where it is stuck--it will loop forever at this point, assuming it goes untouched.

5. If the clock is stuck, repeating the steps beginnging at step 1 may or may not fix the issue.  It is a shot in the dark as to whether it will get stuck or not.  I have tried this on two FRDM-K22F boards and Board 1 gets stuck anyways between 50%-75& of the time, and Board 2 gets stuck about 10% of the time.

Let me know if there are any additional questions or the source doesn't build.

Kevin

Original Attachment has been moved to: MK22F51212_2.zip

[kevinlfw]

I've also found two potential bugs in KBOOT 1.2, please let me know if these changes should be made, or are made in the latest KBOOT release.  These same potential issues are also in KBOOT v2:

In configure_clocks function in clock_Config_K22F512.cfile:

        // 9. Now set the dividers

        SIM_CLKDIV1 = SIM_CLKDIV1_OUTDIV1(div1 - 1) |

                      SIM_CLKDIV1_OUTDIV1(div1 - 1) |

                      SIM_CLKDIV1_OUTDIV2(div3 - 1) |

                      SIM_CLKDIV1_OUTDIV4(div4 - 1); /* Update system prescalers */

should be:

        // 9. Now set the dividers

        SIM_CLKDIV1 = SIM_CLKDIV1_OUTDIV1(div1 - 1) |

                      SIM_CLKDIV1_OUTDIV2(div2 - 1) |

                      SIM_CLKDIV1_OUTDIV3(div3 - 1) |

                      SIM_CLKDIV1_OUTDIV4(div4 - 1); /* Update system prescalers */

and, in target_config.h:

enum _target_clocks

{

    kDefaultClock               = 20971520u,

    kHIRC                       = 48000000u,

    kMinCoreClockWithUsbSupport = 20000000u,

    kMaxCoreClock               = 120000000u,

    kMaxBusClock                = 60000000u,

    kMaxFlexBusClock            = 50000000u,

    kMaxFlashClock              = 25000000u,

    kDivider_Min                = 1,

    kDivider_Max                = 16,

};

should be:

enum _target_clocks

{

    kDefaultClock               = 20971520u,

    kHIRC                       = 48000000u,

    kMinCoreClockWithUsbSupport = 20000000u,

    kMaxCoreClock               = 120000000u,

    kMaxBusClock                = 60000000u,

    kMaxFlexBusClock            = 30000000u,

    kMaxFlashClock              = 25000000u,

    kDivider_Min                = 1,

    kDivider_Max                = 16,

};

As the reference manual for MK22FN512VLH12 (K22P121M120SF7RM.pdf) states that the max FlexBus Clock is 30MHz.

[bryancole-b4682]

Hi Kevin,

Yes, both of the above instances were incorrect in the bootloader source code. The changes you suggested are correct as well. I confirmed these with the bootloader development team. The team will be updating the bootloader source code.

Thanks,

Bryan

[kevinlfw]

I have tested the FRDM-K64F and the FRDM-KL43Z and neither board seems to run into the same problems (though the KL43Z doesn't have PLL).

I tested the "FRDMK22F_KSDK.zip" found on the attached discussion here (also in original post): Adapting KDS project for KBOOT flash resident bootloader to see if I can recreate the issue with the provided code and I could.

The only thing that needed to be changed from the original zipped project is enabling the clock gates and calling BOARD_ClockInit() at the immediate beginning of main, so it should look like this:

int main(void)

{

  SIM->SCGC5 |= ( SIM_SCGC5_PORTA_MASK

        | SIM_SCGC5_PORTB_MASK

        | SIM_SCGC5_PORTC_MASK

        | SIM_SCGC5_PORTD_MASK

        | SIM_SCGC5_PORTE_MASK );

  BOARD_ClockInit();

  GPIO_DRV_Init(NULL, ledPins);

Also FWIW, I did try to use the new KBOOT (v2) that was just released last week, but that didn't seem to make a difference either.