ST-Link Utility checksum feature

[acebrian]

Posted on October 24, 2014 at 10:38

Is there any way to calculate device flash (or selected flash sectors) checksum in ST-Link Utility.

Is a common feature in other programmers that I cannot found in latest ST-Link Utility v3.4.0. Do you plan to add it to future release of ST-Link Utility? Best regards. #st-link

[Tesla DeLorean]

Posted on October 24, 2014 at 14:27

And this should be 16-bit, 32-bit, a sum, a CRC?

[acebrian]

Posted on October 29, 2014 at 09:03

Some manufacturer programmers use a checksum and others use a CRC and the same happens with the 16/32 bit width. From my taste, a 32-bit checksum should be enough and easy to do.

One important related feature is the ability to pick the desired flash sectors for checksum calculation (in a similar way than picking the desired flash sectors for erase). This is very important when some flash sectors are used for EEPROM emulation in order to skip those sectors in checksum calculation.

Best regards.

[ivani]

Posted on October 29, 2014 at 10:35 Such a function is better implemented by some post-linker tool but not by the chip programmer. The reason is that you will probably want that the same checksum will be programmed also when you load your code by the debugging probe. I think all programming toolsets have the option to generate various checksum variants and sizes.

[Tesla DeLorean]

Posted on October 29, 2014 at 16:21

My question was rhetorical, the problem starts simple and gets so specific and nuanced it really should be the job of the person writing the firmware to get it checksummed and packaged to fit the actual requirements. This becomes especially true when compression and encryption are used.

A college intern should be able to code an application specific solution in a couple of hours.

[Nickname306_O]

Posted on October 31, 2014 at 17:39

Hi acebrian,

Could you please tell me whether your application requires computing and writing the cheksum  into Flash as in EWARM toolchain or just computing it ? Best Regards, Nouha

[Tesla DeLorean]

Posted on October 31, 2014 at 18:05

As posed the question suggests it's the 16-bit or 32-bit sum

Where the coherency of the image can be checked when reading the file, or off the part, and perhaps expressed in the programming file for the Golden ROM

03/25/2011 11:48 AM 131,072 hi8_U20_8bin
03/25/2011 11:48 AM 131,072 lo8_U18_AB7F.bin
2 File(s) 262,144 bytes
0 Dir(s) 402,133,188,608 bytes free

Most of these would be a sum of bytes truncated to 16-bits. Personally I prefer CRC's as the byte ordering would impact them.

[acebrian]

Posted on November 04, 2014 at 10:15

Just computing is enough (with flash sector selection as for erase).

My firmware has his own embedded checksum and at startup the microcontroller halts if the checksum doesn't match. I use srecord tool to automatically compute and insert the checksum in the firmware hex file. This embedded checksum algorithm and value is hidden to user and it has nothing to do with the programmer checksum. I use the programmer checksum for production. The manufacturer receives an hex file with the programmer checksum in the filename (i.e: myfirmware_12345678.hex). When he programs the board checks that the checksum match with filename checksum. This ensures that the hex file is not corrupted and that the microcontroller has been correctly programmed. This is why any programmer checksum algorithm is good for me. Best regards.