STM32_Programmer_cli STL LIb crc calculation error

[ivanobono]

I'm currently working on a project using an STM32G473RCT6. I've integrated the STL Lib (Self-Test Library) and intended to use STM32_Programmer_cli.exe with the -sl option to add the CRC block.

The application starts at 0x08040000 and continues for a maximum of 128K, up to 0x08060000.

• There will therefore be an area of 0x20000/1024=128 CRCs, which will occupy 128×4=512 bytes.

• In practice, the application itself can only occupy 0x1FE00 bytes because the last block will be available for the CRC Area.

• Based on the STL documentation, these CRCs will be inserted at address 0x08060000−512=0x0805FE00.

The command I'm using is:

STM32_Programmer_cli.exe -sl "firmware.bin" 0x08040000 0x08060000 0x400

The resulting binary has the entire section between the end of the original binary and 0x0805FE00 padded with 0xFF.

Upon checking the CRCs that were inserted starting from 0x0805FE00, I can see that the first ones correctly match the CRC of the application blocks. However, when it reaches the CRCs corresponding to the 0xFF-filled area, they are set to 0xFFFFFFFF, which I believe is incorrect (the CRC32 803.2 for an area full of 0xFF is 0xB83AFFF4).

Is this an error in the tool, or am I doing something wrong?

[Kouthair]

Hello there Ivanobono,

The CRC is only computed on the user program data only according to UM3167 Section 4.1.3 and not the remaining empty area between the end of the binary and the start of the CRC Area if the binary doesn't fill that region.
I hope that answers your question.

Best regards,
Kouthair.

[ivanobono]

Rereading, I noticed that in section 4.1.3 it is stated:

The user application has to align the end of the subset with the end address of the binary area. If a set of complete sections is tested exclusively, the subset end address has to be aligned with the end of the last tested section

But this means that to have the test working every time I make a change to the source code, since the .bin file changes size, I would have to compile without launch STM32_Programmer_cli , check where the .bin ends, modify the last subset section accordingly, recompile now launching STM32_Programmer_cli.

Certainly, it works this way, but it seems impractical.

I personally preferred to build an alternative utility that calculates the correct CRC over the entire flash (including the part beyond the binary which is filled with 0xFF) so the test subsets are configured to check everything up to the end of the available space (at the beginning of the CRC area), and I can make changes to the source without having to worry about adapting the subsets anymore.

[Christophe VRIGNAUD]

Hello @ivanobono,

The user application has to align the end of the subset with the end address of the binary area. If a set of complete sections is tested exclusively, the subset end address has to be aligned with the end of the last tested section

=> This concerns the subset declaration in the test code. You can define only one subset for all the flash (supposing that you have only one binary for your application) and your subset will have end address = end address of the flash. Or you can define a subset or several subset containing only some flash sections and your subset will have end address = end address of the last flash section in the subset. This allows the users flexibility to define tests in the way that is most appropriate for their application.

In all cases, the CRC is calculated on the binary, not on the empty flash areas.

The way you are doing is correct. the tool will calculate the CRC only on the binary and put the CRCs are the right place at the end of the flash. The CRC area has CRCs for the code and 0xFF bytes for the empty flash areas.

You don't have to change the STM32_Programmer_CLI command line unless your code needs more than the 128K area that you have defined.

[Christophe VRIGNAUD]

You are in the case of example 2 of Figure 4 of UM3167.

[ivanobono]

Thank you for your feedback, but I believe there is a fundamental misunderstanding regarding the practical implementation of the STL (Self-Test Library).

The core of the issue is the mismatch between what the CLI tool generates and what the STL library expects during runtime when a fixed memory range is used.

1. The Goal: To avoid modifying the source code (subset boundaries) every time the binary size changes due to a new compilation, I want to define a fixed subset area (e.g., from 0x08040000 to 0x0805FE00).

2. The Problem with the CLI Tool: When I use STM32_Programmer_cli.exe -sl, the tool fills the CRC slots for the "empty" (padded with 0xFF) blocks with 0xFFFFFFFF.

3. The Runtime Failure: During the execution of the STL library on the target, the hardware/software CRC engine calculates the actual CRC32 of those 0xFF padded areas. As I noted, the CRC32 of a 1KB block of 0xFF is 0xB83AFFF4, not 0xFFFFFFFF.

The Contradiction: If I follow your suggestion and define a subset that covers the entire flash (to have flexibility), the STL test will fail as soon as it reaches the first empty block, because the calculated CRC (0xB83AFFF4) will not match the value stored by the tool (0xFFFFFFFF).

Therefore, your statement:

'The CRC area has CRCs for the code and 0xFF bytes for the empty flash areas' is exactly why the tool seems "broken" or impractical for a real-world workflow. To make the test pass with a fixed subset, the CLI tool should calculate the real CRC of the padding bytes, rather than just filling the slots with 0xFF.

Otherwise, the only "official" way to use the tool is to manually shrink the subset at every compilation to match the exact .bin size, which is an inefficient workflow for any CI/CD pipeline.

Could you please clarify if there is a way to force STM32_Programmer_cli to calculate the real CRC even for padding areas?