Kinetis Bootloader v2.0.0 Reference Manual.pdf
Kinetis Bootloader Demo Application User'sGuide.pdf
1. 型号
CPU_MKL26Z256VLH4,
已有最接近的型号为CPU_MKL25Z128VLK4
开发环境:KEIL 5.16
2. Bootloader
NXP_Kinetis_Bootloader_2_0_0
www.nxp.com/KBOOT.
3. Choosing a starting point
Thefirst step is to download the latest bootloader release. Updates for thebootloader are released multiple times per year, so having the latest packageis important for finding the
beststarting point for your port. To find the most recent bootloader release,www.nxp.com/KBOOT.
Theeasiest way to port the bootloader is to choose a supported target that is theclosest match to the desired target MCU.
NOTE
Justbecause a supported device has a similar part number to the desired target MCU,it may not necessarily be the best starting point. To determine the best match,reference the data sheet and reference manual for all of the supported Kinetisdevices.
4. Preliminary porting tasks
Allreferences to paths in the rest of this chapter are relative to the root of theextracted Kinetis bootloader package. The container folder is named FSL_Kinetis_Bootloader_
4.1 Download device header files
Themost manual process in porting the bootloader to a new target is editing thedevice header files. This process is very time consuming and error prone, soNXP provides CMSIS-compatible packages for all Kinetis devices that containbootloader-compatible device header files. These packages can be found on theproduct page for the MCU.
NOTE
It isnot recommended to proceed with a port if a package does
not yetexist for the desired target MCU.
In thedownloaded package, locate the folder with the header files. The folder isnamed after the MCU (for example, “MK64F12”) and contains a unique header file for each
peripheralin addition to system_
4.2 Copy the closest match
Copythe folder of the MCU that most closely matches the target MCU in the /targets folderof the bootloader source tree. Rename it to coincide with the target MCU part number.
Oncethe files are copied, browse the newly created folder. Rename all files thathave reference to the device from which they were copied. The following filesneed to be renamed:
•clock_config_
•hardware_init_
•memory_map_
•peripherals_
Thefollowing files should be copied from their location in /src/platform/devices/
•system_
•system_
•
4.3 Provide device startup file (vectortable)
Adevice-specific startup file is a key piece to the port. The bootloader may notfunction correctly without the correct vector table. A startup file from theclosest match MCU can
be usedas a template, but it is strongly recommended that the file be thoroughlychecked before using it in the port due to differences in interrupt vectormappings between Kinetis
devices.
Thestartup file should be created and placed into the/targets/
chain>folder. Startup files are always assembly (*.s) and are namedstartup_
NOTE
The16-byte Flash Configuration Field should be carefully set
in thebootloader image. The Flash Configuration Field is
placedat the offset 0x400 in the bootloader image. The field is documented in the SOCreference manual under a the subsection "Flash Configuration Field"of the "Flash Memory Module" chapter. To change the default 16-bytevalue for the
fieldin the template startup_
project,the following steps are needed:
1. Openthe startup_
2.Locate the symbol where Flash Configuration Field is
specified.The symbol name is "__FlashConfig" The 16-
byteFlash Configuration Field data is enclosed with
__FlashConfigand __FlashConfig_End symbols in the
startup_
3.Change the 16-byte value to the desired data. For example
set theflash security byte, enable or disable backdoor
accesskey, specify the 8-byte backdoor key, and so on.
4. Oncethe field is updated, save the startup_
andclose the text editor.
4.4 Clean up the IAR project
KEIL工程与以下内容相似。
Thisexample uses the IAR tool chain for the new project. Other supported toolchains can be used in a similar manner.
Thefolder copy performed in step 1.2.2 copies more than just source code files.Inside of the newly created /targets/
likeand the files that need to be touched.
注:link文件MKL25Z128xxx4_application_0x0000.scf可通过project->option->link->scatterfile进行选择更改为MKL26Z256xxx4_application_0x0000.scf。不可在工程目录link中直接更改,否则会出现如下错误:
assemblingMKL25Z128xxx4_application_0x0000.scf...
E:\Project\mSphere\software\bootloader\NXP_Kinetis_Bootloader_2_0_0\targets\common\linker\arm\MKL26Z4\MKL25Z128xxx4_application_0x0000.scf(1):error: #11-D: unrecognized preprocessingdirective
E:\Project\mSphere\software\bootloader\NXP_Kinetis_Bootloader_2_0_0\targets\common\linker\arm\MKL26Z4\MKL25Z128xxx4_application_0x0000.scf: #! armcc -E
E:\Project\mSphere\software\bootloader\NXP_Kinetis_Bootloader_2_0_0\targets\common\linker\arm\MKL26Z4\MKL25Z128xxx4_application_0x0000.scf:..\..\..\common\linker\arm\MKL26Z4\MKL25Z128xxx4_application_0x0000.scf: 0warnings, 1 error
E:\Project\mSphere\software\bootloader\NXP_Kinetis_Bootloader_2_0_0\targets\common\linker\arm\MKL26Z4\MKL25Z128xxx4_application_0x0000.scf:error: A1905U: Pre-processor step failed for'..\..\..\common\linker\arm\MKL26Z4\MKL25Z128xxx4_application_0x0000.scf'
可直接用编辑工程文件freedom_bootloader.uvprojx(freedom_bootloader为工程名),修改
--feedback_type=unused,noiw
--predefine="-D__ram_vector_table__=1"
……
MKL26Z256xxx4_application_0x0000.scf文件是修改MKL25Z128xxx4_application_0x0000.scf中
#define m_text_start 0x0000a410
#define m_text_size 0x0003FBF0
重命名后得到。
Oncechanges have been made, update the project to reference the target MCU. Thiscan be found in the project options.
4.5 Bootloader peripherals
Thereis a C/C++ preprocessor define that is used by the bootloader source toconfigure the bootloader based on the target MCU. This define must be updatedto reference the
correctset of device-specific header files.
Thelinker file needs to be replaced if the memory configuration of the target MCU differsfrom the closest match. This is done in the linker settings, which is also partof the project options.
注:project->option->C/C++->Include Path需要更改MKL25Z4->MKL26Z4,增加..\..\..\..\src\platform\devices\MKL26Z4\drivers
4.6 Primary porting tasks
Actualporting work can begin when the basic file structure and source files are inplace.
Thissection describes which files need to be modified and how to modify them.
4.6.1 Bootloader peripherals
Thereare two steps required to enable and configure the desired peripherals on thetarget MCU:
• Choosingwhich peripherals can be used by the bootloader.
•Configuring the hardware at a low level to enable access to those peripherals.
4.6.1.1 Supported peripherals
Thebootloader uses the peripherals_
thatcontains active peripheral information and pointers to configurationstructures. This file is found in /targets/
It’simportant to only place configurations for peripherals that are present on thetarget MCU. Otherwise, the processor generates fault conditions when trying toinitialize a
peripheralthat is not physically present.
Interms of the content of each entry in the g_peripherals[] table, it isrecommended to reuse existing entries and only modify the .instance member. Forexample, starting with
thefollowing UART0 member, it can be changed to UART1 by simply
changing.instance from “0” to “1”.
{
.typeMask= kPeripheralType_UART,
.instance= 0,
.pinmuxConfig= uart_pinmux_config,
.controlInterface= &g_scuartControlInterface;
.byteInterface= &g_scuartByteInterfacek;
.packetInterface= &g_framingPacketInterface;
}
Whenthe table has all required entries, it must be terminated with a null { 0 } entry.
4.6.1.2 Peripheral initialization
Oncethe desired peripheral configuration has been selected, the low levelinitialization must be accounted for. The bootloader automatically enables theclock and configures the
peripheral,so the only thing required for the port is to tell the bootloader which pins touse for each peripheral. This is handled in the peripherals_pinmux.h file in/targets/
deviceswhen it comes to pin routing. Each function should be checked for correctness
andmodified as needed.
4.6.1.3 Clock initialization
TheKinetis bootloader typically uses the MCU’s default clockconfiguration. This is done to avoid dependencies on external components andsimplify use. In some situations,the default clock configuration cannot be useddue to accuracy requirements of supported peripherals. On devices that haveon-chip USB and CAN, the default system configuration is not suficient and thebootloader configures the device to run from the
high-precisioninternal reference clock (IRC) if available. Otherwise, it depends on the externaloscillator supply.
Thebootloader uses the clock_config_
If not,the functions within clock_config_
4.6.2 Bootloader configuration
Thebootloader must be configured in terms of the features it supports and thespecific memory map for the target device. Features can be turned on or off byusing #define statements in the bootloader_config.h file in/targets/
One ofthe most important bootloader configuration choices is where to set the start address(vector table) of the user application. This is determined by the BL_APP_VECTOR_TABLE_ADDRESSdefine in bootloader_config.h. Most bootloader configurations choose to placethe user application at address 0xA000 because that accommodates the fullfeatured bootloader image. It’s possible to move this start addressif the resulting port reduces features (and thus, code size) of the bootloader.
NOTE
Loadthe Release build of the flash-resident bootloader if you
plan toplace the user application at 0xA000. Loading the
Debugbuild requires you to move the application address
beyondthe end of the bootloader image. This address can be
determinedfrom the bootloader map file.
4.6.3 Bootloader memory map configuration
The MCUdevice memory map and flash configuration must be defined for proper operationof the bootloader. The device memory map is defined in the g_memoryMap[] structureof the memory_map_
memory_map_entry_tg_memoryMap[] = {
{0x00000000,0x000fffff, kMemoryIsExecutable, &g_flashMemoryInterface}, // Flash array
(1024KB)
{0x1fff0000,0x2002ffff, kMemoryIsExecutable, &g_normalMemoryInterface}, // SRAM (256KB)
{0x40000000,0x4007ffff, kMemoryNotExecutable, &g_deviceMemoryInterface}, // AIPS
peripherals
{0x400ff000,0x400fffff, kMemoryNotExecutable, &g_deviceMemoryInterface}, // GPIO
{0xe0000000,0xe00fffff, kMemoryNotExecutable, &g_deviceMemoryInterface}, // M4 private
peripherals
{0} //Terminator
};
Inaddition to the device memory map, the correct SRAM initialization file must beselected according to the target device. This file is split based on ARM?Cortex?-M4 and
Cortex-M0+based devices, so the likelihood of having to change it is low.
Thesram_init_cm4.c file is located in /src/memory/src and its alternative is sram_init_cm0plus.c.
5. 裁剪
Bootloader_config.h
//
//Bootloader configuration options
//
//! @namePeripheral configuration macros
//@{
#if!defined(BL_CONFIG_UART)
#defineBL_CONFIG_UART (1)
#endif
#if!defined(BL_CONFIG_I2C)
#defineBL_CONFIG_I2C (0)
#endif
#if!defined(BL_CONFIG_SPI)
#defineBL_CONFIG_SPI (0)
#endif
#if!defined(BL_CONFIG_USB_HID)
#defineBL_CONFIG_USB_HID (0)
#endif
#if!defined(BL_CONFIG_USB_MSC)
#defineBL_CONFIG_USB_MSC (0)
#endif
仅保留UART。
6. Windows GUI updater application
This section describes how to use the Windows GUI updater application,KinetisFlashTool.exe, to install an example user application onto the platform.
6.1 Installing the user application
The FRDM-K22F platform is used in this example. Similar steps can be used forother development platforms.
1. Press the "Reset" button on the platform.
2. Navigate Windows Explorer to the
3. Double-click the KinetisFlashTool.exe file to launch the app.
4. Connect the device.
•Select the COM23 device from the "Port" drop-down box.
•Click the "Connect" button.
Select the image file.
•Select the led_demo_FRDM-K22F_a000.bin application image from the
•Set the target address to 0xA000.
Update the image.
•Click the "Update" button to write the application image to thedevice flash.
•Wait for the application to start. The waiting time is determined by thetimeout parameter.
7. At this point, the LED(s) on the target board should be noticablyblinking indicating that the Kinetis Bootloader
successfully installed the led_demo user application.
8. Reprogram the device without exiting the application if you re-enterthe bootloader by pressing the boot pin button (see
Appendix B to determine if the platform has a boot pin button) andresetting the board.
9. Click the"Close" button at the top right corner when finished.
注:端口为UART0,波特率为57600.目标地址为0x8000。若不删减bootloader,bootloader自身程序超过0x8000,导致更新程序失败。或修改合适的目标地址,需要修改应用程序*.scf文件的地址配置。
演示程序:E:\Project\mSphere\software\bootloader\NXP_Kinetis_Bootloader_2_0_0\apps\led_demo\MKL26Z4\mdk\led_demo_freedom_8000\output\Debug\led_demo_freedom_8000.hex
7. The Kinetis Bootloader ConfigurationArea (BCA)
The Kinetisbootloader reads data from the Bootloader Configuration Area (BCA) to configurevarious features of the bootloader. The BCA resides in flash memory at offset 0x3C0from the beginning of the user application, and provides all of the parameters neededto configure the Kinetis bootloader operation. For uninitialized flash, theKinetis bootloader uses a predefined default configuration. A host applicationcan use the Kinetis bootloader to program the BCA for use during subsequentinitializations of the bootloader.
NOTE
Flashloader doesnot support this feature.
Table 2-1. Configuration Fields forthe Kinetis bootloader
Offset |
Size (bytes) |
Configuration Field |
Description |
0x00 - 0x03 |
4 |
tag |
Magic number to verify bootloader configuration is valid. Must be set to 'kcfg'. |
0x04 - 0x07 |
4 |
crcStartAddress |
Start address for application image CRC check. To generate the CRC, see the CRC chapter. |
0x08 - 0x0B |
4 |
crcByteCount |
Byte count for application image CRC check. |
0x0C - 0x0F |
4 |
crcExpectedValue |
Expected CRC value for application CRC check. |
0x10 |
1 |
enabledPeripherals |
Bitfield of peripherals to enable. bit 0 UART bit 1 I2C
bit 2 SPI bit 3 CAN
bit 4 USB-HID
bit 7 USB MSC |
0x11 |
1 |
i2cSlaveAddress |
If not 0xFF, used as the 7-bit I2C slave address. |
0x12 - 0x13 |
2 |
peripheralDetectionTimeout |
If not 0xFF, used as the timeout in milliseconds for active peripheral detection. |
0x14 - 0x15 |
2 |
usbVid |
Sets the USB Vendor ID reported by the device during enumeration. |
0x16- 0x17 |
2 |
usbPid |
Sets the USB Product ID reported by the device during enumeration. |
0x18 - 0x1B |
4 |
usbStringsPointer |
Sets the USB Strings reported by the device during enumeration. |
0x1C |
1 |
clockFlags |
See clockFlags Configuration Field. |
0x1D |
1 |
clockDivider |
Inverted value of the divider used for core and bus clocks when in high- speed mode. |
0x1E |
1 |
bootFlags |
One's complement of direct boot flag. 0xFE represents direct boot. |
0x1F |
1 |
pad0 |
Reserved, set to 0xFF. |
0x20 - 0x23 |
4 |
mmcauConfigPointer |
Reserved, holds a pointer value to the MMCAU configuration. |
0x24 - 0x27 |
4 |
keyBlobPointer |
Reserved, holds a value to the key blob array used to configure OTFAD. |
0x28 |
1 |
pad1 |
Reserved. |
0x29 |
1 |
canConfig1 |
ClkSel[1], PropSeg[3], SpeedIndex[4] |
0x2A - 0x2B |
2 |
canConfig2 |
Pdiv[8], Pseg[3], Pseg2[3], rjw[2] |
0x2C - 0x2D |
2 |
canTxId |
txId |
0x2E - 0x2F |
2 |
canRxId |
rxId |
0x30 - 0x33 |
4 |
qspiConfigBlockPointer |
QuadSPI configuration block pointer |