![]() Segger J-Link can do this to get ‘unlimited’ breakpoints (see Software and Hardware Breakpoints, then this is changing the code, and as such invalidates the CRC checksum/check. There is one potential problem with the CRC calculation done by the bootloader: If your debugger probe modifies the flash memory for setting breakpoints (e.g. Below is the command line to insert that CRC32 value into the binary file at offset 0x3C4: srec_cat -generate 0x3cc 0x3d0 -constant-b-e 0x52E406B8 4 tinyK22_KBOOT_led_demo.bin -binary -exclude 0x3cc 0x3d0 -output newWithCRC32.bin -BinaryĬRC Checks and Debugging With ‘Software’ Breakpoints It first fills the memory from 0x0000 to 0x1000 with the 0xff filler, then cuts out the area between 0x400 to 0x1000, calculates the checksum and issues it on the console. To calculate the CRC32 value from a Binary, I use the following command line: srec_cat tinyK22_KBOOT_led_demo.bin -binary -fill 0xff 0x0000 0x1000 -crop 0x0400 0x1000 -Bit_Reverse -CRC32LE 0x1000 -Bit_Reverse -XOR 0xff -crop 0x1000 0x1004 -Output -hex_dump That value with the number of bytes and start address then can be entered into the sources like this: This then produces something like this: srec_cat tinyK22_KBOOT_led_demo.srec -fill 0xff 0xc000 0xd000 -crop 0xc400 0xd000 -Bit_Reverse -CRC32LE 0x1000 -Bit_Reverse -XOR 0xff -crop 0x1000 0x1004 -Output -hex_dump Which gives something like: Format: Motorola S-Record To find out the size, use the linker map file or use srec_info: srec_info inputfile.srec Ideally, the vector table at 0xC000 and the BCA at 0xC3C0 would be included into the CRC, but KBOOT does not support this, so for simplicity, I keep it excluded from the CRC calculation. -crop 0x1000 0x1004 -Output -HEX_DUMP: Crop everything around the generated CRC32 and dump the output to the console.-Bit_Reverse -CRC32LE 0x1000 -Bit_Reverse -XOR 0xff: used to generate the correct CRC32 as expected by KBOOT and store it the given address.This does not include the vector table and BCA itself. -crop 0xc400 0xD000: just keep the area for the CRC calculation.Kudos go to Robert Poor (see ) who has found out the correct command line to generate the CRC32 needed by KBOOT. CRC With S-Record FilesĪ better approach is using the srec_cat utility ( CRC Checksum Generation with ‘SRecord’ Tools for GNU and Eclipse): srec_cat tinyK22_KBOOT_led_demo.srec -fill 0xff 0xc000 0xd000 -crop 0xc400 0xD000 -Bit_Reverse -CRC32LE 0x1000 -Bit_Reverse -XOR 0xff -crop 0x1000 0x1004 -Output -hex_dump in the startup file as in this tutorial:īut this is a very painful process, and only works with. That BCA can be implemented as a struct in C as in Getting Started: ROM Bootloader on the NXP FRDM-KL03Z Board or it could be part of the assembly code e.g. So if the application gets loaded at 0xC000 (as used in this tutorial), the BCA is located at 0xC3C0. That ROM bootloader for the KL03Z does not implement the checksum feature, so I would have to build a flash-flash resident bootloader as explained in Flash-Resident USB-HID Bootloader with the NXP Kinetis K22 Microcontroller.įor the flash-resident bootloader, the BCA has part of the application to be loaded as well and located at offset 0x3C0 - right after the vector table located at offset 0x0000. As explained in Getting Started: ROM Bootloader on the NXP FRDM-KL03Z Board, it configures the ROM bootloader. The bootloader is configured with a BCA (Bootloader Configuration Area). Additionally, it gives tips for debugging the bootloaded application. ![]() This article explains how to calculate the CRC32 for KBOOT, both from binary and S-Record files, and how to insert the values into the BCA (Bootloader Configuration Area). ![]()
0 Comments
Leave a Reply. |