- ROM Bootloader
KL43 chip with Kinetis Bootloader residing in the on on-chip read-only memory (ROM), can interface with USB, I2C, SPI, and LPUART peripherals in slave mode and respond to the commands sent by a master (or host) communicating on one of those ports.
When KL43 chip with a blank flash, the Kinetis bootloader will execute automatically. Once the flash is programmed, the value of the FOPT field at Flash address0x40D will determine if the device boots the ROM bootloader or the user application in flash.
The FTFA_FOPT [BOOTSRC_SEL] will select if boot from customer application (Flash) or boot from ROM bootloader.
For example:
When Flash address 0x40D value is 0xFF, boot source is ROM bootloader;
When Flash address 0x40D value is 0x3D, boot source is Flash (Customer application).
There with hardware pin(/BOOTCFG0) to control if boot from user application or ROM bootloader with FTFA_FOPT[BOOTPIN_OPT] bit . When FTFA_FOPT[BOOTPIN_OPT] = 0, it forces boot from ROM if /BOOTCFG0 pin set to 0.
- blhost utility application
The blhost utility is an example host program used to interface with devices running the Kinetis bootloader. The blhost application is released as part of Kinetis bootloader release package available on www.freescale.com/KBOOT . The blhost application default located at C:\Freescale\FSL_Kinetis_Bootloader_1_1_0\bin\win folder.
About how to use blhost application, please check KBLHOSTUG document for more detailed info.
- Call Rom Bootloader from customer application
In general, if customer application was programmed, the boot option should be change to Boot from Flash. If customer want to call the ROM bootloader during the application running, customer can refer below example.
Set a signal for application code to call the ROM bootloader, such as press a button.
In this demo, we use FRDM-KL43Z board SW3 (PTC3) to call the ROM bootloader.
//Initalize PTEC3 as GPIO button
PORT_Init (PORTC, PORT_MODULE_BUTTON_MODE, PIN_3, 0, NULL);
GPIO_Init (GPIOC, GPIO_PIN_INPUT, PIN_3);
The bootloader entry point for customer application to call the ROM bootloader.
//prototype of the entry point definition
void run_bootloader(void * arg);
//Variables
uint32_t runBootloaderAddress;
void (*runBootloader)(void * arg);
// Read the function address from the ROM API tree.
runBootloaderAddress = **(uint32_t **)(0x1c00001c);
runBootloader = (void (*)(void * arg))runBootloaderAddress;
in <main.c> routine to call the ROM bootloader:
while (1)
{
if ((GPIOC_PDIR & (1 << 3)) == 0)
{
// Start the bootloader.
runBootloader(NULL);
}
}
Press SW3 button of FRDM-KL43Z board will call ROM bootloader.
Customer could continue to debug the code until the ROM bootloader be called. If customer debug into the runBootloader(NULL) function, there will stop at fixed address: 0x1C00_00C0.
In fact, during call the ROM bootloader function , there will setting some parameters and then reset the KL43.
When KL43 back from reset, it will boot from ROM bootloader. That reset will cause debugger disconnect with the KL43 product.
More detailed info, please check attached demo code.
BTW: The demo project is [frdm_led_test] inside of KL43 baremetal sample code, which could be downloaded from here.
