Calculating application image CRC for KBOOT V2

[kevinlfw]

I'm looking to implement the bootloader integrity checking and need to set the CRC start address, byte count, and expected value found in KBOOT V2. 

The reference manual states the crcStartAddress is "generally the start address of the application image, where it resides in the flash or QuadSPI memory." so I'm curious if that start address of the application image would be BL_APP_VECTOR_TABLE_ADDRESS, or is it where main is placed (0xa464 in my case).  Also, what do you recommend I do to figure out the crcByteCount?  Can I just pull a number/calculation out of the .map file, and if so, which one?

Lastly, how should I actually calculate the application CRC?  It seems like a utility or tool should be available where I can easily generate the CRC for my application.  The documentation doesn't really specify much to go off of so I'm hoping you can help.

Using IAR EWARM, FRDM-K22F board, KBOOT V2 freedom bootloader, app vector table address set to 0xA000, USB HID peripheral enabled.

Thanks,

Kevin

[bobpaddock]

SRecord 1.64  is a tool for calculating many types of CRCs etc.

[jay_heng · Accepted solution]

Yes, KinetisFlashTool can help to calculate the application CRC as you requested.

For image downloading, all the common file formats are supported by KinetisFlashTool, but for automatic BCA CRC data generation, currently only .bin file can be supported. Note: target bootloader can only recognise bin data sent from host.

One possible workaround is that you should convert the file into bin format, and then pass the bin file to KinetisFlashTool

Typical user case:

crcStartAddress = BL_APP_VECTOR_TABLE_ADDRESS

crcByteCount = whole size of application image (bin file)

Best Regards,

Jay

[kevinlfw]

After further review, using the KinetisFlashTool will calculate the application CRC, where you will then "Save" the BCA data after you "Config" the BCA area in the tool.  After you "Save" the BCA to the .bin file, you will then Update the device in the "Update" tab where it will write the CRC information for you.  Is this correct?

Does this only work with .bin files?  What about .elf, .s19, .srec, etc. files? 

[egoodii]

IAR has options on the 'linker' tab to calculate a matching checksum, using the same address values.  I can only hope that this time the V2 bootloader instructions give you FULL details about CRC, which starts with the polynomial but also needs the seed, and bit/byte directions, and sometimes there is even a 'final math op' in CRC work...   This process wants to put the result in a global var __checksum, which is best allocated 'by itself' in a linker block, which to place within this bootloader-table makes a bit of a hassle. And 'something' in code has to refer to it so that the linker will actually allocate the space, and not 'skip as unused'.  Of course I may be doing it all the hard way...

That linker-tab also has a spot to 'fill empty memory' with something so you can work with a 'fixed' end-address.  I fill with 0xDF, as in the Thumb instruction set this is system-call parameter 0xDF (#223), and I can 'catch' that in an interrupt handler and perform a reboot (should the PC ever 'get so lost' as to run into this empty space).

[kevinlfw]

What did you enter for the Start address and End address?  I'm assuming if your application starts at 0xA000, and has size of 0x1000, then you would start (fill) at 0xB001 and end at 0x7FFF?

[egoodii]

You don't have to tell it where to 'fill'.  If you start CRC at 0xA410 (past the location for the bootloader table) and end at 0xFFFF, then 'fill' will put your 'known value' everywhere in that range not occupied by explicit contents so that the CRC over said range will be all inclusive of known contents.