Flash Integrity CRC

[Dfarr.1]

I'm trying to piece together the post-build process for flash integrity check using CRC. I'm running on an STM32F777.

So far I've been following:

https://community.st.com/s/question/0D50X0000B9vdDC/how-can-i-calculate-crc-of-image-in-post-build

and

https://www.eevblog.com/forum/microcontrollers/stm32-hex-file-signing-with-crc/

and

https://github.com/ethanhuanginst/STM32CubeIDE-Workshop-2019/tree/master/hands-on/06_F746-DISCO-CRC

But I'm seeing an error (warning?) that these guides don't mention and I haven't been able to find an explanation elsewhere:

warning: The STM32 filter uses 4-byte alignment,

  but unaligned data is present. Use a "--fill 0xNN --within <input>

  --range-padding 4" filter *before* the STM32 filter to fix this problem. See

  srec_info(1) for how to see the data ranges.

I've tried adding the changes suggested by the error message, but they throw additional errors and it feels like a rabbit hole.

What's causing this unaligned data? Can I/should I fix it?

[waclawek.jan]

My crystal cube is hazy today, I don't see clearly what do you do.

JW

[Dfarr.1]

I guess a better question might be what could cause program data misalignment? Are there any IDE settings that can lead to unaligned data in program memory? Or is this something I could have done in source code?

Is it possible to prevent/identify program data misalignment with a toolchain setting?

[waclawek.jan]

What do you mean by "program data"?

What IDE?

If you are talking about the generated binary code, Cortex-M runs in Thumb mode so it executes basically 16-bit instructions, so the basic alignment of binary code is on 2-bytes boundary. The toolchain you are using can easily place the beginning of a chunk of binary code on a 32bit-misaligned 16-bit-aligned starting address using linker script or equivalent, and given the length of code may be arbitrary, as there may be constant data in bytes, the end of data can be on any misaligned address.

Your toolchain may have options and techniques to avoid any of these; or, in post-processing step, srecord can be used to fill up the spaces up to required alignment with some defined pattern (e.g. FFs).

The CRC module in the historically first STM32s worked with fixed 32-bit words (on 'F7 you can already change that) so that's why srec implements the STM32-specific CRC algorithm to work on 32-bit (4-byte) aligned pieces of data.

Of course, you are free to implement any other CRC of your choice, both on PC and mcu side, avoiding any need for alignment. Simply write the CRC in software, or, in case of 'F7, the CRC unit probably can be switched to process bytes (I did not check).

JW

[Tesla DeLorean]

The data/statics might not be a clean rounded/aligned value

Not clear what tools you're using, but assuming GNU/GCC you could add some alignment in the Linker Script (.LD), use a strategically placed . = ALIGN(4)

Or simply fix the srecords command line as the warning suggests, and document those errors warnings. Really shouldn't have to guess at what command line you started with or ended up with or the errors it generated

Probably need to add something like -fill 0xFF --within THING.BIN --range-padding 4

[Dfarr.1]

apologies. I'm fairly new to this. I'm making a lot of assumptions about context/toolchain because this is the ST forums. I'll try to be more clear.

I'm using CubeIDE.

GNU/GCC

My hardware CRC is configured to operate on bytes (I know its slower than word-based, but we're using it elsewhere in our application already).

I do have both hardware and software CRC running on the chip. I haven't been able to get them to match eachother yet on test data, but that's really not necessary. I just need any one CRC running on chip (software or hardware) which matches the srecord CRC. But I haven't been able to compute and append a crc with srecord yet either.

I have tried changing the srecord command to

..\srec_cat output.hex -Intel -fill 0xFF --within output.hex --range-padding 4 -o output_padded.hex -Intel

This throws the following:

srec_cat: output.hex: 1: warning: ignoring garbage lines

srec_cat: output.hex: 96250: file contains no data ( I guess they all became garbage? The file is definitely not empty.)

[waclawek.jan · Accepted solution]

> I'm making a lot of assumptions about context/toolchain because this is the ST forums.

There are at least half a dozen of different toolchains for STM32; gcc may form base of some of them, but that still leaves a lot of options open.

> srec_cat: output.hex: 1: warning: ignoring garbage lines

Sounds like output.hex is not an intelhex file. Look into it. Do you know how intelhex files look like?

JW

[Dfarr.1]

I do have the "-O ihex" option set in the CUBEIDE>Project>Properties>MCU Post Build outputs

So the IDE should perform the conversion from *.elf to *.hex with intel format on build.

I looked up the intel hex format and checked the IDE output.hex file. It does look like an intel hex file.

This is the header (spaces added):

:02 0000 04 0800 F2

[Dfarr.1]

Thanks for pointing me at the hex file format. I think I've found my problem.

Seems like any time a non-header line in the hex file does not contain the full n x 32bits of data, I get this "unaligned data" warning when using the -STM32 flag.

STM32F777

Flash start address 0x08000000

Flash end address 0x081FFFFF

I've been misinterpreting these guides (links above) which say to do this:

srec_cat inputFile.hex -fill 0xFF start_addr end_addr -o outputFile.hex

Seems srecord -fill is non-inclusive of the end address. So changing to this:

srec_cat inputFile.hex -fill 0xFF 0x08000000 0x08200000 -o outputFile.hex

clears up the unaligned data error.

[Tesla DeLorean]

Suspect you need to tell it to be using the Intel format

https://sourceforge.net/p/srecord/discussion/248569/thread/b8fac9db76/?limit=25

Generally the reason I've never bothered with SRecord is that I built equivalent tools decades ago to perform specific tasks without all the circus and command line voodoo sequences