Started port of Kinetis bootloader KBOOT to K26 MCU

[lucasrangit]

I need help porting the Kinetis bootloader KBOOT to a K26 MCU. I started with the TWR-K65F180M bootloader (flash resident as opposed to ROM resident) and have it building and running on my K26 target. However it currently keeps resetting to `main()` after executing the following line from `configure_clocks()`:

        // Change the Clock source to PLL because MCG switches from FEI to PEE mode

        SIM_BWR_SOPT2_PLLFLLSEL(SIM, 1);

I made the required changes based on the Porting Guide in the KBOOT reference manual but also many more since the port was not straightforward (no USB stack for K26, K65 workarounds, etc...). I still have to address the linker map to put the bootloader and application at a known location and come up with a `BOOT_PIN` alternative since my K26 board not have GPIO. But that is lower priority than getting the bootloader to run and enumerate over USB HS.

The source code with my changes to the Kinetis Bootloader 1.2.0 package is at https://bitbucket.org/lucasrangit/k26_kboot/branch/k26 ​. Please review/try it out and let me know what you think is causing the resets.

Thanks!

[kerryzhou]

Hi Lucas Magasweran,

      If you want to use the KBOOT for K65 on your K26 board, you should have the same external circuit with the TWR-K65F180M.

      From the schematic of TWR-K65F180M, you can get that the external crystal is 16Mhz, what the crystal frequent you are using?

     Because you want to enter in the PEE mode, you should make sure your configuration is in the PLL lock range. The Kboot defined the external clock as 16Mhz:

#define CPU_XTAL_CLK_HZ

16000000U

     If you are not using 16MHZ, you can change an 16Mhz crystal and try again.

Wish it helps you!

If you still have question, please contact me!

Have a great day,

Jingjing

[lucasrangit]

Thanks Jingjing, I missed that define in the port. Unfortunately, it does not resolve the reset. I still suspect this is mainly due to the KBOOT configuration struct not being written properly.

Thanks Mark, I agree with favoring USB MSD because of it's many advantages. I only am trying to make KBOOT first because it already works on a TWR-K65 board and wont require code changes to the application.

When using Kinetis Design Studio (KDS) to build and load a debug build of tower_bootload.elf should I be specifying different options to the J-Link in order to get the bootloader and configuration written to flash properly?

[mjbcswitzerland]

Lucas

If you have a 24MHz crystal instead of 16MHz and you also use this as PLL reference there are two (or three) adjustments to make:

1. For the HS transceiver's PLL you need to set USBPHY_PLL_SIC to the 24MHz divide.

2. You need to ensure that the clock input divider is set to 2 or 3 so that the MCG's PLL's is between 8MHz and 16MHz (unless already matching)

3. You need to ensure that the PLL settings are correct for the PLL to be able to lock (eg. x20 for 120MHz from 12MHz)

There is no difference for an application that is loaded with KBOOT compared to one loaded with USB-MSD so the loader should never dictate the application.

What is your budget for the port (in man-hours or dollars)?

Or are you doing it for hobby/fun?

Regards

Mark

[lucasrangit]

mjbcswitzerland wrote:

If you have a 24MHz crystal instead of 16MHz and you also use this as PLL reference there are two (or three) adjustments to make:

1. For the HS transceiver's PLL you need to set USBPHY_PLL_SIC to the 24MHz divide.

2. You need to ensure that the clock input divider is set to 2 or 3 so that the MCG's PLL's is between 8MHz and 16MHz (unless already matching)

3. You need to ensure that the PLL settings are correct for the PLL to be able to lock (eg. x20 for 120MHz from 12MHz)

Thanks again Mark! This is helping me understand of how the SoC clocks are configured. I found that the K65 startup code I'm porting from had the following defined in src / include / device / MK26F18 / system_MK26F18.h :

#define CLOCK_SETUP 4

This is then used in src / startup / MK26F18 / system_MK26F18.c to configure the clocks for USB operation.

Now, the target enters a signal handler when it executes the following:

#if defined(SYSTEM_SIM_CLKDIV2_VALUE)
  SIM->CLKDIV2 = ((SIM->CLKDIV2) & (uint32_t)(~(SIM_CLKDIV2_USBFRAC_MASK | SIM_CLKDIV2_USBDIV_MASK))) | ((SYSTEM_SIM_CLKDIV2_VALUE) & (SIM_CLKDIV2_USBFRAC_MASK | SIM_CLKDIV2_USBDIV_MASK)); /* Selects the USB clock divider. */
#endif

I can get passed this call if I single-step through SystemInit() but it will enter the signal handler on the next clock configuration immediately following the code above:

#if defined(SYSTEM_SIM_CLKDIV3_VALUE)
  SIM->CLKDIV3 = ((SIM->CLKDIV3) & (uint32_t)(~(SIM_CLKDIV3_PLLFLLFRAC_MASK | SIM_CLKDIV3_PLLFLLDIV_MASK))) | ((SYSTEM_SIM_CLKDIV3_VALUE) & (SIM_CLKDIV3_PLLFLLFRAC_MASK | SIM_CLKDIV3_PLLFLLDIV_MASK)); /* Selects the PLLFLL clock divider. */
#endif

I'll stare at this some more and refer to the reference manual to see if I can figure out how this could fail.

What is your budget for the port (in man-hours or dollars)?

Or are you doing it for hobby/fun?

I use a K26 at work but this bootloader development is just fun/learning.

[mjbcswitzerland]

Lucas

I see no problems with writing to SIM_CLKDIV2 and SIM_CLKDIV3. These are just setting some clock divider and even if the values written didn't make sense there is no reason why they would affect the operation.

Possibly it is something just before these lines (?) - eg. the flash clock is out or specification, which causes code to fail.

Try moving the program counter over these instructions (they are not of use at his point in the operation) and see whether the following code fails too - pointing to something out of spec. rather than a register access issue.

>>I use a K26 at work but this bootloader development is just fun/learning.

For hobby work you can simply use the uTasker project since it is free of charge, already solves KBOOT and USB-MSD boot loaders and also allows you to simulate the K26 so that you don't need to guess what is happening - the simulator already tells you in case you are programming anything out of spec. You may also consider it for work later since it will save you and your company lots of development time....

Regards

Mark

[mjbcswitzerland]

Hello Lucas

The K26 is a K65 without Ethernet (and tamper) and it is not necessry to port to it since the same code from a K65 project can run on it as long as it does't access Ethernet (or its tamper inputs) and uses the same crystal.

There is a TWR-K65F180M project at http://www.utasker.com/kinetis/TWR-K65F180M.html which supports KBOOT mode on HS USB as well as USB-MSD loading (composite), plus SD card loading (in one SW).

The project supports also K26 and K65 targets, whereby there is virtually no difference (apart from where switches and LEDs may be connected to force the loader and see its operation).

Regards

Mark

[lucasrangit]

Hi Mark, thanks for the tip. I tried the MK65 code with my K26 board and ran into the same issue (had to recompile since KDS cannot download/flash S-REC files). The only clock difference is the USB HS clock ([E]XTAL0) is 24 MHz vs. 16 MHz.

Your tip lead me to double-checking the clock prescaler and divider options and to realize that the kBootloaderConfigAreaAddress did not contain a valid KBOOT configuration. Because of this, the code writes all 1's to the configuration struct and proceeds to setup with invalid values.

I confirmed address 0xa3c0 in the ELF file on my host contains a valid KBOOT configuration. How do I verify this is getting written to flash at the address expected? BL_APP_VECTOR_TABLE_ADDRESS is defined as 0xa000 and .text is 0x00000410 according to the linker file.

Thanks again.

[mjbcswitzerland]

Hi Lucas

I don't know all details about KBOOT since there are some parts that are not needed for actual practical operation but instead seem a little over-complicated without real advantages. Therefore I just leave these out because the most important concern that I have if that all loaders are compatible - especially since USB-MSD loading is more attractive for most practical usage.

In any case your application will need to be linked to the defined start address (presumably BL_APP_VECTOR_TABLE_ADDRESS) and once the loader has copied it you can just check in Flash to see that it is there and identical to the binary image.

Regards

Mark