ST-Link Utility Checksum changed

[ENind]

Hello,

recently i upgraded my ST-Link Utility from v3.8.0 to v4.2.0, within that change the value of the calculated checksum for the same Intel-HEX files changed. Below there are screenshots for the different ST-Link Utility versions respectively. In the change-log of ST-Link Utility i did not found information regarding a change in checksum calculation.

Please provide information about this changed behavior.

Thank you!

v4.2.0

v3.8.0

[Tesla DeLorean]

Improbable that it is zero, looks consistent with a sum of bytes.

https://www.st.com/content/ccc/resource/technical/document/user_manual/e6/10/d8/80/d6/1d/4a/f2/CD00262073.pdf/files/CD00262073.pdf/jcr:content/translations/en.CD00262073.pdf

"Memory checksum

The checksum is calculated based on an arithmetic sum algorithm, byte per byte. The result is truncated to 32-bit word.

The checksum value is displayed in the log window"

[ENind]

Thank you Clive,

a checksum can be also zero. More precisely, the HEX-file is padded specially in order to produce a zero result using CRC32. However this does not work for ST-Link Utility v4.2.0.

[Tesla DeLorean]

>>a checksum can be also zero

Indeed, but that takes some effort. And is potentially unachievable with a 32-bit sum of bytes. That typically works better for 16-bit truncated values .

Pretty sure ST isn't using CRC32, or their mutation/flavour of it.

There are several intervening versions of the Utilities, and a newer version. The command line option provides a means to generate sums. I think 5 mins of testing could get you a clear understanding of what's being applied.

[ENind]

STM32 use CRC32, see also here:

https://www.iar.com/support/tech-notes/general/calculate-crc32-as-in-stm32-hardware-v.5.50-and-later/

Files with CRC equal to zero can be generated by padding with the actual CRC, see also here:

http://www.sunshine2k.de/articles/coding/crc/understanding_crc.html#ch21

Can you specify the checksum algorithms of ST-Link Utility v3.8.0 and v4.2.0?

You said you can evaluate it in 5 mins of testing.

Thank you for your help!

[Tesla DeLorean]

I'm familiar with the properties of CRC's, I've been using them since the 1980's, so yes feeding the remainder back into the division yields a zero. I think I've discussed it here in the STM32 case going back a decade.

General problem with .HEX files is that have the potential to be sparse, and out of order, the fill character then plays a role.

ST uses an unconventional application of CRC32, this routine on the cite page won't give you the same values. Compute_CRC32_Simple()

I'm saying the someone who understood the mechanics could make a determination of what, or what wasn't, being applied in any given case, pretty quickly.

Sum of bytes is going to be hard/impossible to get to zero across a relatively finite span provided by the firmware/flash size here. A sum of words, the same width as the words, comparatively is going to be a trivial task to sum to zero.

The docs for 4.2.0 and 4.3.0 releases say its a sum of bytes. I don't see it mention CRC, nor Fletcher algorithms.