2014-10-24 01:38 AM
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-link2014-10-24 05:27 AM
And this should be 16-bit, 32-bit, a sum, a CRC?
2014-10-29 01:03 AM
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.
2014-10-29 02:35 AM
2014-10-29 08:21 AM
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.2014-10-31 09:39 AM
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, Nouha2014-10-31 10:05 AM
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 ROM03/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.
2014-11-04 01:15 AM
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.