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.​

[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

[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]

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.

[Florian Moser]

Thank you!

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

[Florian Moser]

Oh ok, that seems not very difficult to me. Thank you!

The uint thing was just an example to make clear, that I just want to use a single number for versioning and not things like V1.4.1.2.3.

As a matter of fact it was a #define value.

[Florian Moser]

I'm just trying to understand that.

Unfortunately I've never seen KEIL asm.

But I know what you mean.