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

[Tesla DeLorean]

PM0214 talks more broadly about the CM4(F)

When the design compiler (silicon) determine a lot of gates and functionality aren't used the get dumped/optimized from the netlist.

The NVIC lacks the gates to manage/generate interrupts beyond the scope of the table describe for each die in the reference manual

[FPutn.1]

So your saying there is no way for the interrupt vectors between 0x0194 and 0x03FC to be activated. What about the reserved vector table entries set to 0x0?

[FPutn.1]

So your saying there is no way for the interrupt vectors between 0x0194 and 0x03FC to be activated. What about the reserved vector table entries set to 0x0?

[Tesla DeLorean]

I'm saying it's probably a demonstrable fact that bits within the NVIC don't exist, and probing the register space you could determine the absolute limits of the silicon as built.

Masking in the SCB->VTOR should also be determinable. Limiting the boundaries on which it can be placed.

An entry of zero in the table is going to immediately fault the MCU

[FPutn.1]

Thanks Tesla,

That was some very helpful information.

Where do you generally start your executable code?

[Tesla DeLorean]

Usually immediately after the usable portion of the vector table, the linker usually makes the determination based on the relative sizes of the sections/segments. In Keil the actual code for Reset_Handler, main(), etc can be quite deep into the image. The linkers in common use tend not to be multi-pass, and place code linearly based on how the objects/libraries are encountered.

If not using any of the NVIC IRQs, it can safely be placed after the system handlers.

Are you coming at this from a "Functional Safety" angle?

[FPutn.1]

In a way, yes. I always stayed clear of the vector table area, and set unused interrupts to a safe return function so that things would keep running. In this particular project I was seeing the processor try to execute at 0x0200 where it accessed unusable memory (0xFFFFFFFD) causing a bus fault. Since that is in the vector table area my thought was an interrupt trigger.

My objective is to remedy this random fault and the random hard fault that occurs when configuring ADC1 after waking up.

I'm debugging with STM32CubeIDE V1.7, gdb server, and ST-LINK/V2. When I compile with -O0 -ggdb the program acts significantly different than if I compile with -Og. The LPUART receiver quits. Also IDE freezes during debug perspective.

There are some powerful debug features in the IDE but after looking through the ST Community pages I don't have a lot of confidence in it's reliability.

Have you used STM32Cude Monitor or STMStudio?

[TDK]

> In this particular project I was seeing the processor try to execute at 0x0200 where it accessed unusable memory (0xFFFFFFFD) causing a bus fault. Since that is in the vector table area my thought was an interrupt trigger.

In the hard fault handler, you can look at the VECTACTIVE bits to determine if the mcu is in an interrupt and if so, which one.

> There are some powerful debug features in the IDE but after looking through the ST Community pages I don't have a lot of confidence in it's reliability.

People like to complain and this is a forum for solving problems, not posting reviews. The folks using the IDE without issue aren't coming here to say it's working. In its current state, STM32CubeIDE is much better than the free offering which preceded it.

I would say more folks are distrusting of CubeMX rather than the IDE, however. Sometimes this distrust is justified, sometimes it's due to user error.

[Tesla DeLorean]

0xFFFFFFFD is a call gate address, to switch context.

Sounds like and issue with the stack frame and local/auto variables. So perhaps bounding issues, variable scope, or errant pointers. Here perhaps how it leaves and interrupt/callback.

Most IRQs dump into Default_Handler via weak linkage. One could make a couple of alternates to bisect possible candidates, but you'd need to enabled the NVIC side IRQs

I'm not a big user of debuggers to understand my code, I use step'n'trace when I need too, but its far behind static analysis and instrumentation.

Tools are generally worth what you pay for them, or the time your invest in them.