Does STM32CubeProgrammer display a CRC (or equivalent) someplace for a hex file upon load? Most programming software I've used in the past has provided this.

[Tesla DeLorean]

Seem to recall ST-LINK Utilities having a 32-bit sum

The tools will do a byte level verify.

General problem moving beyond single ROM programming is that the .HEX file is sparse and can describe multiple regions, frequently MB or GB apart, and the fill patterns and alignment requirements also might change, or be accounted for.

If you need security/assurance in your own code/images, you should check and sign them yourself, and validate them during early execution, or from the loader you have transferring control to them.

Check the STM32 side reporting vs your PC side checking/signing.

[RBack.1]

I do use a checksum inside my image which is verified before the application is run, however I do want the technicians programming my boards to have an indication that they have loaded the correct hex file before programming. There are multiple hex files for the same PCB in my company for different applications

It would also be helpful to be able to read the hex file crc or checksum off of programmed PCBs without connecting them to a communications interface first.

I've looked for a crc or checksum in the ST tools but have been surprised not to find one easily.

[Tesla DeLorean]

I can see a file being provided with a SHA, MD5 or CRC32, but most older tools generated a checksum for the binary data they constructed from the .HEX described content, not the file itself. Having the linker, or post-link, generate a file output name with the MD5 appended is one I've seen used effectively.

While I can see value here, I'm not convinced one solution will make all happy. And what worked in 1980 isn't a solution today.

>>It would also be helpful to be able to read the hex file crc or checksum off of programmed PCBs without connecting them to a communications interface first.

How would that work? Devices frequently have 1-2MB of internal flash, and perhaps 4-256MB external. How does one determine the subset within which the user app occupies?

@Nawres GHARBI​ could the tools always generate and display an MD5, or other suitable/classic HASH, for ALL loaded files, ie of the .HEX, .S19, .ELF, .AXF, .DFU, .BIN, etc. And perhaps minimally authenticate/confirm?

In a form such as this f9k_lap_101.b94de250c8c2fa60389c1479c4ef816a.bin

[Tesla DeLorean]

C:\UBLOX\F9K101>C:\SiLabs\SimplicityStudio\v3\developer\msys\1.0\bin\md5sum f9k_lap_101.b94de250c8c2fa60389c1479c4ef816a.bin

b94de250c8c2fa60389c1479c4ef816a *f9k_lap_101.b94de250c8c2fa60389c1479c4ef816a.bin

[RBack.1]

Using MPLab as an example, it would provide a checksum for the entire memory range for the part I was using. For the memory locations not specified in the hex file, the blank value of 0xFF would be used as the programmer would erase the part before programming. When reading the hex file from a programmed device, the checksum would be calculated over the entire memory range, even if only a portion of the memory was read (although in my case I'd always read the entire image).

I do admit that I haven't used external Flash, however, and that would add a complication to this

[Tesla DeLorean]

The tools certainly need some critical review as to what features are desirable in real use cases, also a lot of QA so they are significantly more robust and better tested.

Yes, I understand the mechanics of what several decades worth of EPROM and Universal Programmers did. Often a mixed assortment of 16-bit, or 32-bit sums.

However, we're not dealing with devices with several dozen KB, or a few hundred, in increasingly more cases.

The erase/fill patterns are different on several of the STM32

Flash line widths, and alignment aren't byte level on many of the STM32

Span, size and content are not well constrained in Intel or Motorola Hex files.

Memory may be partitioned to hold resources, keys, configuration, calibration, or stage updates, etc.

Reading back multiple MB can be a multi-minute exercise, although ST has some target side code that can checksum in a more timely fashion.

STM32 Cube Programmer could do well with a two phase method, internal hashing could quickly determine if a byte level compare was worth enduring, for example. And also to fail quickly/immediately.

The more features the tools have, the LESS desirable they are for production personnel to be touching. Most tools for production use I've worked on, we have to provide the entire front-end so there's minimal opportunity to mis-program devices, and there's a non-ambiguous PASS / FAIL indication, not 3 or 4 pop-ups.

There should be more focus on DLL and CLI methods so as better to "skin" the underlying operation and interfaces.

[waclawek.jan]

> it would provide a checksum for the entire memory range for the part I was using

This is highly nontrivial. Take for example:

> blank value of 0xFF would be used

except that not all STM32 use 0xFF as blank FLASH.

Then there are requirements to put informations like option bytes to the hex/bin/s/whatever "transport" format. And - as mentioned - external memories'. Then there are other peculiarities and they just appear as new devices with new features are introduced. How are you going to cater for those?

You can think of an entire scripting language, describing the way how the checksum is ought to be calculated. For inspiration (and determent) - read srecord's manual.

JW

[RBack.1]

You make good points. My goal in this post wasn't to request a feature in STM32CubeProgrammer as much as to find out if that feature already exists. It seems the answer to that is "No" and I will need to verify the correct versions are programmed through other ways.

[Pavel A.]

> I do want the technicians programming my boards to have an indication that they have loaded the correct hex file before programming.

This is not hard to do.

As Tesla wrote, you can publish MD5 or sha of the firmware files (hex, elf, bin or whatever) for the technicians to check before programming.

You can put an easily visible version number near start of the image so that it can be read by a human after programming.

Then the firmware itself can check its integrity when the MCU runs (as part of production test),

As Jan wrote, it can check also external memories and option bytes and signal if anything is missing.