Kinetis Bootloader V2.0 for MK22FN1M0AVMC12

[pulsatrixp1]

Hello,

I am planning to use the microcontroller MK22FN1M0AVMC12  in a custom board and I need to include bootloader capabilities on it.

I have been looking into the KBOOT Kinetis Bootloader V2.0 and have some questions regarding its use for this specific microcontroller:

1. I see there is a bootloader for MK22F51212, which is basically the same microcontroller I intend to use but with less memory. Does this bootloader work 'out of the box' for the MK22FN1M0AVMC12? Should I do any modification to the code?

2. I also see there are multiple alternatives in the folder of the bootloader provided for Kinetis Design Studio: Flashloader, Flashloader_loader, Freedom_bootloader, and tower_bootloader. Since I am not using any of the development kits like the freedom or the tower, which version should I use? What would be the differences?

3. In my application I am planning to have only two buttons available. Is this enough for the complete bootloader capabilities? I would mainly like to be able to update my firmware through USB with no additional connections. From what I see the bootloader could be either started at startup when a USB is connected and attempting to establish bootloader connection, or even calling a function from my application, but I just want to make sure that no extra pins are required to be available, since as I mentioned, the application will only have two GPIOs available as buttons.

Thank you in advance!

Ivan

[kerryzhou]

Hello Pulsatrix P1,

    You can't use the K22 flash bootloader in the KBOOT2.0 directly, because this bootloader is not compatible with MK22FN1M0AVMC12 , you need to do the porting.

    You can refer to Kinetis Bootloader v2.0.0 Reference Manual.pdf in folder:: NXP_Kinetis_Bootloader_2_0_0\doc\

   Page 131, chapter 10 Kinetis bootloader porting.

  There has some posts for your reference:

  https://community.nxp.com/message/829169?commentID=829169#comment-829169 

Kinetis Bootloader TWR-K21F120M 

Now answer your 3 questions:

1. You need to do porting, please refer to Kinetis Bootloader v2.0.0 Reference Manual.pdf.

2. Flashloader and Flashloader_loader together is the once used flash bootloader, after you download the application code, this bootloader will be disappear.

  Freedom_bootloader, and tower_bootloader, can always be used. Freedom is used for FRDM-k22f120m board, tower is used for TWR-K22F120M board.

3. The KBOOT2.0 already contains the USB bootloader, you can port it. But just modify the according pins and the start file, system files to your own board's code.

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mjbcswitzerland]

Hi

There are various K22 derivatives that are not compatible so if you have a K22F1M0 you may find the TWR kit version closest.

In case of problems or need for more flexibility see also
http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF

which also includes a K22F1M0 120M target (Kboot UART, KBOOT USB, USB-MSD, SD card, memory stick, Developer's loader, UART SREC/UART iHEX, USB-CDC).

Regards

Mark

http://www.utasker.com/kinetis/FRDM-K22F.html
http://www.utasker.com/kinetis/TWR-K22F120M.html
http://www.utasker.com/kinetis/BLAZE_K22.html

[pulsatrixp1]

Hi Mark, 

Thanks for your reply and the extra info.

Do you have any suggestion for my question 3? Do I need any specific IOs available? or can I just rely on a timer and a couple of GPIOs available?

Thanks!

Ivan

[mjbcswitzerland]

Ivan

I don't know about the original KBOOT's capabilities but the uTasker alternatives use switches as you describe which are configured for each board as required. It also allows an application to command the loader mode in a RAM mailbox (application sets pattern in RAM mailbox and commands a SW reset -> loader detects this and stays in the loader rather than starting the application).

Other alternatives are to allow the loader to run for a short time - if no communication is detected it then starts the application (or mixtures of these).

Regards

Mark

[mjbcswitzerland]

Ivan

Note that the uTasker serial loader has integral support for your chip (including the most popular USB-MSD mode, which is used by the Blaze project - and is Win 10, MAC OS, Linux compatible and can recognise bin, SREC or iHex files).

There is a thread about configuring for custom boards from the Blaze target at http://www.utasker.com/forum/index.php?topic=1951.0
which also removes any porting requirements and allows building with almost any IDE.

Regards

Mark

[pulsatrixp1]

Hi Mark,

I have been testing the uTasker bootloader in USB-MSD mode following some of your tutorials. I am using an MK22FN1M0AVMC12 in a custom board that has followed the design from the kit TWR-K21F120MA. 

By changing my Led pin and configuring the bootloader to this TWR board, and configuring it to disable the watchdog and do not force the bootloader mode (as below) 

#define WATCHDOG_DISABLE()     (1)

#define FORCE_BOOT()       (0)

I was able to load my application as well, when changing the starting address of the application from: 

m_interrupts (RX) : ORIGIN = 0x00000000, LENGTH = 0x00000400
m_flash_config (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
m_text (RX) : ORIGIN = 0x00000410, LENGTH = 0x000FFBF0
m_data (RW) : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000
m_data_2 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00010000

to:

m_interrupts (RX) : ORIGIN = 0x00008080, LENGTH = 0x00000400
m_flash_config (RX) : ORIGIN = 0x00008480, LENGTH = 0x00000010
m_text (RX) : ORIGIN = 0x00008490, LENGTH = 0x000FFBF0-0x8080 
m_data (RW) : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000
m_data_2 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00010000

I have also tested a similar modification but starting at 0x8200, and changing the line below

From #define ROOT_FILE_ENTRIES         4

To #define ROOT_FILE_ENTRIES         16

This, following the indication of one of your posts that for all interrupts to work correctly, vector table must be 512 byte. This results in the memory map indicated below:

  m_interrupts          (RX)  : ORIGIN = 0x00008200, LENGTH = 0x00000400

  m_flash_config        (RX)  : ORIGIN = 0x00008600, LENGTH = 0x00000010

  m_text                (RX)  : ORIGIN = 0x00008610, LENGTH = 0x000FFBF0-0x8200

  m_data                (RW)  : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000

  m_data_2              (RW)  : ORIGIN = 0x20000000, LENGTH = 0x00010000

Now, in both cases I see my application starts as I activate a Led in certain pattern, but if I place the lines of this same Led activation further in my code, it seems these lines are never reached and the program stops. Device is not resetting since watchdog is inactive, and is not going to bootloader mode since this is also forced to be disabled.

On every reset I see the initial part of my program runs (by activating a buzzer), but the rest of my program does not continue until the end, and my Led blinking routine seems not to be reached.

Do you have any suggestions on what may be happening that prevents the complete application to run? Is there a restriction on where the interrupt vectors should start? I saw there is an option to move these to RAM, but I would prefer to keep them in FLASH; should a different address be used for this purpose (or an additional modification in my application code that I am missing?)

In addition, if I will be using interrupts of different kinds (GPIOs, timers), will these interrupts work as normal just by changing the start of the interrupt vector, or should additional modifications be done to guarantee the interrupt functionality?

Thank you in advance!

Best Regards,

Ivan

[mjbcswitzerland]

Hi Ivan

There is a guide for application compatibility in appendix B of the serial loader user's guide with a list of points to be checked [http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF]
In addition there is a guide for Teensy users to ensure compatibility at http://www.utasker.com/forum/index.php?topic=1869.0

It sounds as though your code is starting but it may have a problem with its clock initialisation (the loader will already initialise it) which doesn't handle the case correctly, or it may be due to interrupts, although your changes to ensure correct operation in Flash are correct - however, make sure that you set the VBA in your start-up code to match!

The best thing to do to identify it is to step through your code with a debugger - there is no problem debugging with a loader installed - and then you can find out where it hangs, check that the VBA is set to match your flash vector location, etc.

Good luck

Regards

Mark

[pulsatrixp1]

Hi Mark,

Thanks for your reply.

When I debug my code (the application with the modified start address) with the bootloader present it runs normally, but it only hangs when I program it by dragging the file in to the disk.

I have verified the VBA (for the case of 0x8200: SCB->VTOR = 0x8200; ) but the behaviour is the same.  When debugging the bootloader, and then dragging the file, the program hangs and shows a "No source available" error. Does this tell you any indication of why it could be failing? or is this just because it has jumped to start the application which is a code not known by the debugger since it is debugging the bootloader and not the application?

How could I reproduce the error debugging my application with the bootloader present? I have checked the lists but it seems I am following the steps suggested, with no effect on the behaviour previously described.

Do you have any other suggestion?

Thank you,

Best Regards,

Ivan

[mjbcswitzerland]

Ivan

If you load your code using the loader it sounds as though the result I flash is not the same as when you load the loader and your code together. If possible, do a Flash memory comparison of the two case because I suspect a difference.

Possibilities are that the loader

- is loading your code to a "different start address" than expected (check the load address configured in the loader carefully).

- is "not copying the complete file" (check the maximum application size that you have configured in the loader to ensure that it is not set smaller that your actual application binary file)

Regards

Mark

[pulsatrixp1]

Hi Mark,

Thanks to your suggestions I have solved the issue. It was related with the clock configuration together with a UART getting a reference clock that was not correct.

Best,

Ivan