With more boards coming with their own bootloaders, let’s dive into the NXP FRDM-KL03Z, including errata pitfalls, configuration, UART, and pin muxing.
A bootloader on a microcontroller is a very useful thing. It allows me to update the firmware in the field if necessary. There are many ways to use and make a bootloader (see Serial Bootloader for the Freedom Board with Processor Expert) . But such a bootloader needs some space in FLASH, plus it needs to be programmed first on a blank device, so a JTAG programmer is needed. That’s why vendors have started including a ROM bootloader into their devices: the microcontroller comes out of the factory with a bootloader in FLASH. So instead writing my bootloader, I can use the one in the ROM.
And as with everything, there are pros and cons of that approach.
Several of the newer NXP Kinetis microcontrollers include a ROM bootloader. I have selected the NXP FRDM-KL03Z board for my experiments because it is inexpensive (less than $20) and a tiny microcontroller useful for smaller applications. And that KL03Z is present on the Ultimate Hacking Keyboard which sparked my interest. In this article I’ ll share my experience and journey to use the ROM bootloader on the KL03Z (ARM Cortex-M0+, 32 KByte of FLASH. 2 KB SRAM in a 24QFN Package) :
The source code used in this article can be found on GitHub (see Links section at the end) .
There are different ways how to communicate with the bootloader (I²C, SPI, UART, USB HID, USB MSD, CAN) . The bootloader uses a special communication protocol, and the KBOOT software includes GUI and command line utilities to communicate with the device.
The ROM Bootloader resides in the ROM starting at 0x1c00200 and uses some part of the RAM while the bootloader is running:
It would be useful to have the sources and memory map of the ROM bootloader available. That way, it would be possible to re-use some of the bootloader functions from the application to save FLASH space.
The bootloader could be called by the application with the following piece of code:
With the above code, the application can enter the bootloader any time.
During POR (Power on Reset) or a normal reset, it can be configured if the microcontroller enters the ROM bootloader or directly boots from the normal FLASH.
This is controlled by several things:
Below is the diagram of the boot process:
So the ROM bootloader is entered if:
The NMI pin is on pin 19 of the KL03Z32VFK4:
On the FRDM-KL03Z the NMI pin is routed to the SW3 push button:
The button is present on the FRDM-KL03Z board here:
As outlined above, the NMI pin can be used to enter the bootloader. On which pins the bootloader can communicate is documented in the reference manual. The KL03Z can communicate over UART, SPI and I²C:
The UART (PTB1, PTB2) is routed to the OpenSDA USB CDC of the K20, and the I2C (PTB3, PTB4) are available on the J2 header:
The bootloader is configured by a structure located at 0x3C0 in FLASH (after the vector table starting at address 0x0:
To configure the bootloader and the BCA, I use the following implementation:
Note that the bootloader will select the first ‘working’ communication channel! I had an issue that on the I2C bus another device was sending data during bootloader boot-up, causing the bootloader listening to the I2C bus instead to the UART. I recommend only to enable the needed communication channels in the BCA settings.
Be careful with the FlashConfig (FOPT) configuration! If not done right, you might brick your part! See “ How (not) to Secure my Microcontroller “
Using the macro:
I can turn on/off the BCA. If turned off (set to 0) , the BCA signature will not be used, and the bootloader ignores the BCA.
with the corresponding placement in the linker file (see Defining Variables at Absolute Addresses with gcc) :
Same for the Flash Configuration (FOPT) : declared a memory area:
And placed it in the linker section like this:
If that configuration area is not properly set up, then running the bootloader might fail. I highly recommend to erase the KL03Z flash starting playing with the FRDM-KL03Z board, as the preloaded demo application seems to confuse the bootloader. To erase the FLASH, I’ m using the SEGGER OpenSDA firmware and the SEGGER J-Link J-Flash Lite program which is free of charge for non-production purposes:
Select the device:
Then erase the chip:
With this, the BCA is erased and set to default 0xFF memory pattern.
To make an initial connection to the ROM bootloader after erased the FLASH, connect a USB cable to the OpenSDA USB port:
Determine the virtual COM port (e.g. using the Windows Device Manager) :
Then do a Reset while the SW3/NMI pin pulled LOW:
There is no visual sign at all to show that the microcontroller is in bootloader mode now.
Errata e8059
Because of this, I only was able to connect with 19200 baud (and not always!) . So make sure you are using 19200 baud!
Both the used communication channel (I2C, UART, SPI) and the speed (baud) is selected at the first communication attempt. To change the communication speed or communication channel, the KL03Z has to be reset first!
The KinetisFlashTool (for Windows) is located in
The blhost tool is located in
Then press ‘Connect’ , and hopefully it connects (otherwise retry) :
With the blhost command line tool, use
Make sure that the COM port is not already used (close the KinetisFlashTool) .
The first command after power-on might be lost (yet another entry in the errata) : In that case, cancel the command with CTRL-C:
Then try it again, the second time it usually works:
Success! We are able to talk with the bootloader!
I was further able to improve above situation after considering the e8086 in the errata:
So I added a 10K pullup to the LPUART Rx pin:
With lots of trial-and-error, I managed to get a stable bootloader UART connection. Here is what I did:
That way I have been able to use for example 57600:
I have put on GitHub three blinky programs you can use to test the bootloader:
If using the Flash tool, browse for the image file and use the Update button:
The same with the blhost command line utility looks like this:
If using S19/S-Record files, there is the ‘flash-image’ command:
Then do the programming:
I have no explanation, as nothing in my flash was protected or secured.
