[solved] What is the proper method for initializing the interrupt vector table?

[FPutn.1]

Using the STM32L452. According to PM0214 Rev 10 page 40 there are 256 exceptions utilizing memory 0x0000 to 0x0400. According to RM0394 Rev 4 page 324 Table 46 only identifies 84 interrupts utilizing memory up to 0x0190.

In order to be safe shouldn't the unused interrupt vectors point to a return function and shouldn't the executable code be placed at 0x0400 or above?

[simosilva]

Hi @FPutn.1​ 

In my short experience the cases are 2:

• if you place and flash your code at the beginning of the bank, here the __Vectors are placed into first position. Also, if you need to have some sort of headers in a fixed region, make sure to offset it leaving enough space for all the interrupts
• if you place your code somewhere in the middle of the flash, place it with an offset equal to the first power of 2 that can contain all the interrupts IDs, for example, with a max interrupt ID of 178words -> 178*4=712 the closest power of 2 is 1024, and this means an offset of 0x400

As @Community member​  said, all the unused IRQ handlers fall into the weak default handler, in case you need you can declare manually in your code all the single IRQs you need for debug, otherwise just handle them in the default handler.

[FPutn.1]

Your example confirms my thought that the executable code should be placed at 0x0400 or above.

Thanks.

[Piranha]

That alignment is only for a vector table. The executable code has no such requirement.

[simosilva]

You're totally right and the precisation is due, but if not specified in other ways the vector table will be placed at the begin of the executable code, from there my toughts

[FPutn.1]

Thanks to all of you who responded. From your advice I was able to track the culprit down to the transmit routine.

Conclusion:

While trying to load the transmitter register with data, location 0x20028000 is read which is outside of accessible memory which causes the fault.

Fault Analyzer:

1)    Buss, memory management or usage fault (FORCED).

2)    Precise data access violation (PRECISERR).

3)    Register content during fault exception:

a.    Stack Pointer (PSP) at 0x200088C0.

b.    Link Register at 0x802C2B1.

c.     Program Counter at 0x802C2DA. 

The fault happened while executing huart->Instance->TDR = (uint8_t)(*pdata8bits & 0xFFU);

1104                          huart->Instance->TDR = (uint8_t)(*pdata8bits & 0xFFU);

0x0802c2d8: 0x0000fb69  ldr    r3, [r7, #28]

0x0802c2da: 0x00001a78  ldrb   r2, [r3, #0]            r3 contains 0x20028000

0x20028000 is at the end of accessible memory. Reading a word from this location causes a bus fault.

Again, thanks for all your help.

[simosilva]

Is this another question or whathever? in case you think your answer as been solved consider to add [solved] to the title of the thread so that others can find rapidly a solution to their problems.

Such kind of bus faults are common in this case, this happen when a fault with IDnumber > 128 when you use an offset of just 0x200 instead of 0x400, the MSB responsible for 128+LSBs is just ignored, and so the fault with IDnumber-128 is erroeously served, causing a spurious push into the stack. when returning from this spurious IRQ handler, the registers will not have consistency and this is what cause the hard/bus fault.