Can some constants be stored in .isr_table section? STM32F1 microcontroller

Question

Background

I have some microcontroller experience (Atmel AVR, PIC18, PIC32), but I'm pretty new in STM32.

I need to maintain/refresh some old project written by another developer who for some reasons can't explain this code. Basically whole project needs to be moved from CooCox to STM32Cube IDE and needs serious refactoring.

I understand practically everything in that project except one thing.

---

Problem

I have found, that there are some constants in the .isr_vector section.

• software version
• probably build/release date (2020-05-26)
• serial number (which is overwritten in the .hex file later, before device programming)

---

Code and details

#define VECTORS __attribute__ ((section (".isr_vector")))

#define VERSION 0x0348

// (...)

#define VERSION_L(VERSION&0xFF)
#define VERSION_H(VERSION>>8)

// (...)

const unsigned char VECTORS FREE3[]         = "-------";
const unsigned char VECTORS SERIAL_NUMBER[] = {0xcf,0x93};
const unsigned char VECTORS FREE2[]         = "-----";
const unsigned char VECTORS VERSION[]       = {VERSION_L, VERSION_H, 0, 0, 20, 0, 5, 0, 26, 0 };
const unsigned char VECTORS NAME[]          = " --------------------";
const unsigned char VECTORS FREE1[]         = "---";

I have no original linker file for this project, but I believe it was default and generated by CooCox.

I have some hex file which was used in production and I found that 0xCF93 (initial serial number) is here:

I don't understand why this data stored in the interrupt vector table section. It looks pretty smart way to store stuff like this at some "known place" without custom linker script etc.

1. Is this normal / common practise in STM32 programming?

2. How can I be sure that real vector table will be allocated correctly (before these constants)?

"Real vector table" is in startup_stm32f10x_md.c - autogenerated CMSIS file.

Answer 1

This is not at all normal or a good idea.

As you can see though, it works. The main reason it is not a good idea is because it is difficult to maintain, as you are finding out.

The correct way to do it is to put your header in a custom named section and edit the linker script to put this after .isr_vector and before .text or .init etc.

I suspect the person who set this up either didn't want to do the work or didn't know how, or perhaps the IDE they were using was too simplistic to allow custom linker scripts.

If you want to carry on hi-jacking the .isr_vector section for your image header, there are three ways you can get the real vector to still be where it needs to be:

1. Edit your linker script to specify that .isr_vector from a file called startup* goes before the same section from other files (but if you are editing the linker script anyway you may as well pick your own section name).

2. Edit the project settings so that the startup assembler unit appears earlier on the linker command line than the file with the header (GNU ld preserves the order of input sections in the output, I don't know about others)

3. Just cross your fingers and then check the build output to see if it worked. There is a 50/50 chance the sections are in the right order with no changes.