Kinetis Bootloader to Update Multiple Devices in a Network for Cortex-M4

Document created by Alice_Yang Employee on Sep 29, 2015Last modified by ebiz_ws_prod on Dec 13, 2017
Version 17Show Document
  • View in full screen mode

@@This article describes how to do in-system reprogramming of Kinetis for Cortex-M4 core devices using standard communication media such as SCI. Most of the codes are written in C so that make it easy to migrate to other MCUs. The solution has been adopted by customers.


This bootloader is based on FRDM-K22 demo board and KDS3.0. The bootloader and user application source codes are provided. GUI is also provided. Customer can make their own bootloader applications based on them. The application can be used to upgrade single target board and multi boards connected through networks such as RS485. The bootloader application checks the availability of the nodes between the input address range, and upgrades firmware nodes one by one automatically.


Key features of the bootloader:

  • Able to update (or just verify) multiple devices in a network.
  • Application code and bootloader code are in separated projects, convenient for mass production and firmware upgrading.
  • Bootloader code size is small, only around 3k, which reduces on chip memory resources.
  • Source code available, easy for reading and migrating.


For Cortex-M0+ products, please refer to here :Kinetis Bootloader to Update Multiple Devices in a Network - for Cortex-M0+ , it based on FRDM-KL26.

The main difference between Cortex-M4 and Cortex-M0+ is the FLASH program routine.

- In Cotex-M4 core kinetis, we need copy the Flash operating routines to RAM. In the bootloader code, the copy to ram code is realized in the function of “FLASH_Initialization()”:

Byte buffer[200]={0};


- In Cotex M0+ core kinetis, we do not need to copy the Flash operating routines to RAM. Platform Control Register (MCM_PLACR) is added. The MCM_PLACR register selects the arbitration policy for the crossbar masters and configures the flash memory controller. Enabling ESFC bit can stall flash controller when flash is busy.  Setting ESFC bit can well-balance time sequence of Flash reading and writing – when writing Flash, reading Flash instruction can wait, and vice versa. Using ESFC bit can make our flash programming easier. Thus one Flash can write itself, which is not possible for other one Flash MCU without ESFC bit control.

ESFC bit is easy to be set in C code:



For more information, please see attached document and code.


User can also download the document and source code from Github:

Original Attachment has been moved to:

Original Attachment has been moved to:

5 people found this helpful