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.

[rN856O7P]

I'm hitting the same exact problem. I agree with everything @ivanobono said. As a user, we currently seem to have two options:

1) Use STM32_Programmer_cli => This means we have to provide the exact end address of the binary for subset.EndAddr, which requires one compilation run to determine the binary size in the first place.

2) Write our own script to add a CRC area to the elf file => Then we can use subset.EndAddr = last address of flash, and it will correctly compute checksums even for unused sections. 

It would be nice if such behaviour could be included in future versions of the Cube Programmer.   

[Kouthair]

Hello everyone!

At the moment, @ivanobono, it is not possible to force STM32_Programmer_CLI to calculate the real CRC for padding areas. 
@rN856O7P  as a workaround you could add padding to the file up to the CRC area, in this thread case it would be padding the file with 0xFF up to 0x0805FE00, this would make the command compute the CRC even on that area because it was manually added so you don't have to compile the binary.

Kouthair

[ivanobono]

from ST CUBE IDE, is there a way to automatically add padding to the generated binary, so as to prepare it for the STM32_Programmer_CLI command that happens as POST-BUILD?

[Kouthair]

Well, there isn't some sort of a built-in option or something that does this for you that I am aware of. But you could technically achieve this.

I'd suggest making a simple script or a program to execute post build in STM32CubeIDE (you could set this up here Project -> Proprieties -> C/C++ Build -> Settings -> Build Steps -> Post-build steps) that adds padding up to the CRC area.
An example of this would be (I've used a PowerShell Script in this example):
1) Make a "file_name.ps1" file with the following script:

$startAddr = 0x00000000
$endAddr = 0x00020000
$sliceSize = 0x400
$crcWordSize = 4

$crcSize = (($endAddr - $startAddr) / $sliceSize) * $crcWordSize
$padSize = $endAddr - $startAddr - $crcSize

$binFile = "binary_file_path.bin"
$currentSize = (Get-Item $binFile).Length

if ($currentSize -lt $padSize) {
 $padBytes = $padSize - $currentSize
 $fs = [System.IO.File]::OpenWrite($binFile)
 $fs.Seek(0,'End') | Out-Null
 $buffer = New-Object byte[] $padBytes
 [byte]255 | ForEach-Object {for($i=0;$i -lt $padBytes;$i++){$buffer[$i]=$_}}
 $fs.Write($buffer,0,$padBytes)
 $fs.Close()
}

This script checks if the file requires padding to up to the CRC area and adds it if needed.

2) Add the following to the post-build command:

 

powershell -ExecutionPolicy Bypass -File "path_to_script.ps1"
&& 
"path_to\STM32_Programmer_CLI.exe" -sl "${ProjDirPath}\Debug\${ProjName}.bin" 0x08040000 0x08060000 0x400

 

This would execute the script & add the CRC accordingly.

3) Build your project and it should output the .bin file, padded if it is not the correct size, and has the CRC area added at the end.

 

I've tried this setup, and it works like you've described. But from what you've told me, you have already made a utility that does this or something similar for you, but this could be a different approach. I hope it helps you in some way.

[ivanobono]

OK, this could be a solution. I'll leave the burden of testing the script to another forum member because I've already developed a dedicated utility for myself.
I still think it would be useful to include this feature in a future release of STM32_Programmer_CLI.