Kinetis Bootloader移植

参考：

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_<version>.Before modifying source code, the following tasks should be performed.

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_<device>.h files. Copy the entire folder into the/src/platform/devices folder of the bootloader tree.

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_<old_device>.c —>clock_config_<new_device>.c

•hardware_init_<old_device>.c —> hardware_init_<new_device>.c

•memory_map_<old_device>.c —> memory_map_<new_device>.c

•peripherals_<old_device>.c —> peripherals_<new_device>.c

Thefollowing files should be copied from their location in /src/platform/devices/

<device>to the new /targets/<device>/src/startup folder:

•system_<device>.c

•system_<device>.h

• <toolchain>/startup_<device>.s

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/<device>/src/startup/<tool

chain>folder. Startup files are always assembly (*.s) and are namedstartup_<device>.s.

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_<device>.s file of the bootloader

project,the following steps are needed:

1. Openthe startup_<device>.s file in a text editor.

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_<device>.sfile

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_<device>.s file

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/<device> folder, locate the IARworkspace file (bootloader.eww) and open it. This image shows an example ofwhat a workspace looks

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"

</Misc>

           <LinkerInputFile></LinkerInputFile>

           <DisabledWarnings>6314</DisabledWarnings>

         </LDads>

       </TargetArmAds>

     </TargetOption>

     <Groups>

       <Group>

         <GroupName>link</GroupName>

         <Files>

           <File>

              <FileName>MKL26Z256xxx4_application_0x0000.scf</FileName>

             <FileType>5</FileType>

              <FilePath>../../../common/linker/arm/MKL26Z4/MKL26Z256xxx4_application_0x0000.scf</FilePath>

           </File>

         </Files>

       </Group>

……

 

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_<device>.c file to define whichperipheral interfaces are active in the bootloader. The source file itselfincludes a single table, g_peripherals[],

thatcontains active peripheral information and pointers to configurationstructures. This file is found in /targets/<device>/src.

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/

<device>/src.The hardware_init_<device>.c file selects the boot pin used by the bootloader,which may need to be changed for the new target MCU.These files most likelyrequire significant changes to account for the differences between

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_<device>.c file in/targets/<device> to override the default clock behavior. If the targetMCU of the port supports USB, this file can be used.

If not,the functions within clock_config_<device>.c can be stubbed out or set towhatever the port requires

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/<device>/src. Examples of using these macros can be seen inbl_command.c (g_commandHandlerTable[] table) in the /src/bootloader/src folder.All checks that reference a BL_* feature can be turned on or off. Examples ofthese features are BL_MIN_PROFILE, BL_HAS_MASS_ERASE andBL_FEATURE_READ_MEMORY.

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_<device>.c file, which can be found in/targets/<device>/src. An example memory map configuration is shown.

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 <install_dir>/bin/Tools/KinetisFlashTool/win directory.

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 <install_dir>/apps/led_demo/

<mcu>/<toolchain>/binaries directory using the "Browse" button.

•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