参考：

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_.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_.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_.c —>clock_config_.c •hardware_init_.c —> hardware_init_.c •memory_map_.c —> memory_map_.c •peripherals_.c —> peripherals_.c Thefollowing files should be copied from their location in /src/platform/devices/ to the new /targets//src/startup folder: •system_.c •system_.h • /startup_.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//src/startup/ chain>folder. Startup files are always assembly (*.s) and are namedstartup_.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_.s file of the bootloader project,the following steps are needed: 1. Openthe startup_.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_.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_.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/ 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:ProjectmSpheresoftwareootloaderNXP_Kinetis_Bootloader_2_0_0 argetscommonlinkerarmMKL26Z4MKL25Z128xxx4_application_0x0000.scf(1):error:  #11-D: unrecognized preprocessingdirective E:ProjectmSpheresoftwareootloaderNXP_Kinetis_Bootloader_2_0_0 argetscommonlinkerarmMKL26Z4MKL25Z128xxx4_application_0x0000.scf:   #! armcc -E E:ProjectmSpheresoftwareootloaderNXP_Kinetis_Bootloader_2_0_0 argetscommonlinkerarmMKL26Z4MKL25Z128xxx4_application_0x0000.scf:......commonlinkerarmMKL26Z4MKL25Z128xxx4_application_0x0000.scf: 0warnings, 1 error E:ProjectmSpheresoftwareootloaderNXP_Kinetis_Bootloader_2_0_0 argetscommonlinkerarmMKL26Z4MKL25Z128xxx4_application_0x0000.scf:error: A1905U: Pre-processor step failed for'......commonlinkerarmMKL26Z4MKL25Z128xxx4_application_0x0000.scf'         可直接用编辑工程文件freedom_bootloader.uvprojx（freedom_bootloader为工程名），修改 --feedback_type=unused,noiw --predefine="-D__ram_vector_table__=1"                        6314                                                link                                     MKL26Z256xxx4_application_0x0000.scf              5               ../../../common/linker/arm/MKL26Z4/MKL26Z256xxx4_application_0x0000.scf                               ……   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，增加........srcplatformdevicesMKL26Z4drivers 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_.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//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/ /src.The hardware_init_.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_.c file in/targets/ 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_.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//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_.c file, which can be found in/targets//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 /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 /apps/led_demo/ //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:ProjectmSpheresoftwareootloaderNXP_Kinetis_Bootloader_2_0_0appsled_demoMKL26Z4mdkled_demo_freedom_8000outputDebugled_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