STM32H5, unable to relocate ISR to 0x08008200, but ok when 0x08008000 or 0x08008400

[MissionEmbedded1]

In developing a bootloader and application for an STM32H5 project using STM32CubeIDE v1.19.0, and STM32H5xx HAL Driver v1.5.0.RC1; when I place the ISR at 0x08008200, I can start the debug process but the application appears to be stuck in void SVC_Handler(void) once an interrupt occurs.

What's interesting is that if I adjust the ISR location to 0x08008000, or 0x08008400, and define VECT_TAB_OFFSET in system_stm32h5xx.c [along with changing definition of .isr_vector to 0x08008000/0x08008400 in LinkerScript.ld] everything behaves as expected; it's only when setting to 0x08008200 that things break.

I previously had a build environment with STM32CubeIDE  v1.15.1 using v1.4.0 STM32Cube MCU package and everything worked fine then.

Any guidance on where to look to zero-in on what might be the culprit?

[TDK · Accepted solution]

The vector table is over 512 bytes but below/at 1024 bytes, so must be aligned to a 1024-byte boundary. 1024 = 0x400.

This is a Cortex restriction.

[MissionEmbedded1]

Ah, ok. That would certainly explain things. Thank you!

[Tesla DeLorean]

I suspect that if you write a value to SCB->VTOR the low order bits will be STZ (stuck-at-zero)

The size of the customer (ST) vector/interrupt table gets baked into the core, and drives the alignment.

[waclawek.jan]

> SCB->VTOR the low order bits will be STZ (stuck-at-zero)

When we discussed this back then, I tried, and they weren't. Instead, the behaviour is, that the processor doesn't ADD the vector offset to VTOR when invoked, instead it ORs it.

It's a detail irrelevant to the rule as the consequence is exactly the same, I just found it amusing. 

JW