Howto: Firmware Version Handling?

[Florian Moser]

I'm new at stm32 processors and have a question about firmware handling. At the moment I'm using an uint value for the firmware version and it seems not to be the correct way. So what's the right way for doing this? Is there a register where I can save this value?

My application: I have a PCB with a STM32F030C8TX processor, a lcd and several buttons on it. The PCB is updated by a hardware-engineer very often, so I end up with many firmware-versions for many different PCB's. With a button-combination the firmware gets printed on the lcd.

Is it possible to store the firmware-version somehow in the hex/elf/bin-file too, to be readable by a non software engineer? Maybe STM32CubeProgrammer can also show the version in the log window?

[Tesla DeLorean]

How did you do it on things prior to the STM32 work?

These are things stored in a string you update. For keeping programing straight people often used a 4-digit hex checksum value that was labeled/stamped on the IC so production placed or programmed the right part.

​

There are some unused vectors at the beginning of Flash that could be identifiable in .HEX file, or the programmers data view.​

​

Perhaps reduce firmwares by using more uniform code that can identify what board it is working on. Perhaps with configuration straps or a small EEPROM, or selected via production staff or the software you write for them to use.​

[Florian Moser]

The STM32 is my first "real" microcontroller. I just begun my work as a software engineer.

Ok, thanks for your advice! I'll try to get into it.

Yeah, in most cases, this isn't a problem. There can be two different displays. I can detect, which display is applied and use the right driver.

But there are hardware versions, where the 4 buttons are arranged differently, but the rest is kept normal.

[waclawek.jan]

I feel your pain, but I don't think there's a ready-made solution for this.

You might want to place the version on a fixed position in FLASH, and then for the non-developers, prepare some simple software tools displaying the number from that fixed position, from the HEX or BIN.

Another way is to place it to a dedicated section and use tools from binutils (objdump) to display content of that section, but that then would work on elf only.

JW

[Florian Moser]

Thank you!

I think I'm going to try it with hex files, as I'm familiar with them.

[berendi]

There is no standard location, you have to make up your in-house standard.

My suggestion is to put it into an unused exception vector entry, e.g. at offset 0x20, exception 8, is not used by any Cortex-M core I know of.

locate the g_pfnVectors: label in the startup_stm32f030*.s file, and put the version number into the 9th .word line:

g_pfnVectors:
 .word _estack
 .word Reset_Handler
 .word NMI_Handler
 .word HardFault_Handler
 .word 0
 .word 0
 .word 0
 .word 0
 .word 0x12345678
 .word 0
 .word 0
 .word SVC_Handler

Important: don't change the number of entries in the list.

It will show up nicely in the .hex file

:020000040800F2
:1000000000100020610A0008AD0A0008AD0A0008CF
:1000100000000000000000000000000000000000E0
:10002000785634120000000000000000AD0A0008FD

of course in low-endian byte order. The firmware itself can read it by accessing *(uint32_t *)0x08000020

It should be possible to use a preprocessor symbol #included from a header instead of a hard-coded value.

[Tesla DeLorean]

Exactly, the "SW Guy" is usually expected to write the firmware and the test station software, or at the very least express his needs/requirements to those who can code it. Could be a union shop, then you don't want to "cross the trades"​

[Pavel A.]

Our solution is to place the extra stuff at  negative offset from the reset handler like this:

(KEIL asm format)

FW_SIGNATURE		EQU 0x4E524246
FW_DESC_SIZE		EQU 64
 
 AREA |.text|, CODE, READONLY
 
; DESCRIPTOR BLOCK immediately before Reset_Handler 
; will be filled by image make tool
 FILL FW_DESC_SIZE, 0xFF, 1
 DCD FW_DESC_SIZE ; Size of preceding block, in bytes
 DCD FW_SIGNATURE ; Magic number
 
Reset_Handler PROC
 EXPORT Reset_Handler [WEAK]
 LDR R0, =SystemInit
 BLX R0
 LDR R0, =__main
 BX R0
 ENDP

So this does not use questionable vectors in the table, but still is easy to find.

-- pa

[Florian Moser]

I'm just trying to understand that.

Unfortunately I've never seen KEIL asm.

But I know what you mean.

[Florian Moser]

Hi Guys, thank you for your help!

I want to share my solution with you:

As I'm using Eclipse as IDE, I thought "Why not use build variables?". So I use a build variable as string. It's very easy to include that variable into the hex/bin/elf file name. I just have to clean the project before building it, if I update the version number. I can also use the build varible in the code as double. I simply convert it with sprintf to a string.

The only problem is, that someone could rename the output file, so I will follow your advice and try to write it into the vector too. I just have to find a way to use the build variable there.

Thank you all!