Could you please release a command line version of the kinetis flash tool and make it not windows only?
Segger J-Link comes with command line tools for Windows, Mac and Linux: SEGGER - The Embedded Experts
I figured out that the Kinetis Flash Tool is used to insert a precalculated CRC into the application binary that later gets transfered to the bootloader running on the target.
I would like to have this NXP-Tool available for Linux & OSX as well. also a cli would be nice for better automation.
does anyone from NXP side has a proposal on how to insert precalculated checksums into the binary ?
I think your question is around the Kinetis Bootloader CRC? I have not used that CRC yet, but I'm using the open source Srecord tool to calculate the CRCs and to add it to my binaries: https://mcuoneclipse.com/2015/04/26/crc-checksum-generation-with-srecord-tools-for-gnu-and-eclipse/
I hope this helps,
Thank you very much for your attention. From what I have read so far, the srecord tool would not completely solve my problem.
to shorten this long story, I need a cross platform solution to populate this struct with the correct values after a build has finished.
this struct is linked to a specific offset in the executable and is evaluated by the bootloader so that it can perform a crc check of the application.
For windows, there is a GUI tool to edit the numbers in the binary. But for macOS and Linux there is no proposed solution for this.
Srecored is the cross platform tool I would use for this.
With the Srecord tool you can add/merge/combine S19 files (see https://mcuoneclipse.com/2016/02/26/merging-s19-files/ ).
So this is what I would do:
a) create a s19 line for that struct at that address with all the values you want need. Or if you prefer use the intel hex or binary format.
b) use the Srecord tool to insert that line into your final application (see above link).
There are many ways how to do a). One way is to do it by hand, by a script. Or have this generated in another project, then use the Srecord tool to extract that piece of code and use it in step b).
seems like srec_cat supports only the generation of CRC32 with a fixed polynomial (0xedb88320). For what ever reason NXP decided to use the MPEG-2 polynomial (0x04C11BD7). For the CRC16 algorithm you cal choose between several polynomials but not for the CRC32 one.
0x04C11BD7 is from EN/IEC 60335-1 used in Ethernet etc. Try the srec command STM32 and see if it gets you what you need, from srec 1.64:
This is a synonym for the −STM32_Little_Endian filter.
−STM32_Little_Endian address −STM32_Big_Endian address
These filters many be use to generate the CRC used by the hardware CRC unit on the STM32 series of ARM MPUs. The algorithm used by the STM32 hardware unit is just a CRC32 with a different polynomial and word-fed instead of byte-fed.
The address is where to place the 4-byte STM32 CRC.
The CRC used is documented in “RM0041, STM32F100xx reference manual”, page 46, chapter “CRC Calculation Unit”, which can be found at http://www.st.com/internet/mcu/product/216844.jsphttp://www.st.com/content/ccc/resource/technical/document/application_note/39/89/da/89/9e/d7/49/b1/DM00068118.pdf/files/…
Could be both K and STM32 parts have the same IP block from some third party, not uncommon, good way to tell is if they share the same bugs.
Code in srec is well structured it would not be hard to copy the STM32 command and make a K command.
there is a mix-up of numbers
srecord stm32 polynomial: 0x04C11DB7
freescale default polynomial: 0x04C11BD7
edit: thank god it's only a typo in the bootloader reference manual. so you are right.
What I just entered on your CRC blog post in hopes of finding a CRC expert here perhaps.
CRC's checking properties only apply over a given block size. While my math skills are a bit fuzzy as reading the many papers and books about CRCs tend to make my eyes glaze over from things like Syndrome Lengths of Galois fields. It is my understanding that a 16 bit CRC's properties only hold over a block size of 4096 bytes minus one bit.
Therefor a 32 bit CRC is needed for anything larger than 4K -1 bit.
Perhaps you can find a math wiz in one of your students to turn all of this Galois crap into a real world paper that us in the Embedded world would actually understand. We don't care about the polynomials, I accept the Math Gurus figured those out, etc. We want to known the formula for CRC5/8/16/32/64 is good for X number of bits, real world kind of stuff we need to know.
I don't care about the polynomial as well, but it is still important to use the correct one if you want to give any meaning to the process of generating and validate the checksum.
I think we should stick with the topic which is the problem of generating a valid crc32 value to insert into the binary on macOS/Linux platforms.
regarding the trust you can have in it, we should better open another thread. or use the one I already opened. (kboot: don't use crc to verify an application image
Retrieving data ...