VTOR description error, ST Cortex-M7 manual

[dbrown]

Posted on November 08, 2017 at 23:58

The description of the VTOR register is incorrect in the ST Cortex-M7 programming manual (PM0253). The description ST Cortex-M4 programming manual (PM0214) is correct. The description in the ARM ARMv7-M Architecture Reference Manual is incomplete.

For reference, here is what I believe is a correct description (from the ARM Cortex-M4 and Cortex-M7 'Generic User Guide' documents), an explanation of what I believe is incorrect in the ST Cortex-M7 programming manual, and what is confusing in the other manuals.

ST Cortex-M4 programming manual (PM0214), section 4.4.4 'Vector table offset register (VTOR)'

This description is correct for both the ST Cortex-M4 and Cortex-M7. The section shows the VTOR register contains:

- bits 31-30 are reserved, and must be zero

- bits 29-9 contain the vector table address bits 29-9

- bits 8-0 are reserved

The VTOR register contains the vector table address, which must be a multiple of 512 bytes and less than 1G byte.

ST Cortex-M7 programming manual (PM0253), section 4.3.4 'Vector Table Offset register'

This description is wrong. The section shows the VTOR register contains:

- bits 31-9 contain the vector table address bits 29-7

- bits 8-0 are reserved

I think there is a typographical error, 'bits 29-7' should read 'bits 29-9'. Clearer would be to use the Cortex-M4 (PM0214) description.

ARM Cortex-M4 Devices Generic User Guide, section 4.3.4 Vector Table Offset Register

ARM Cortex-M7 Devices Generic User Guide, section 4.3.4 Vector Table Offset Register

These are consistent, if confusing. The VTOR register contains:

- bits 31-7 contain the vector table address bits 29-7

- bits 6-0 are reserved

The description implies that VTOR register bits 31-30 are zero/ignored, because bit 29 determines if the table is in the code region or in SRAM. This is consistent with the ARM ARMv7-M Architecture Reference Manual, which states explicitly that address bits 31-30 may be zero.

The description goes on to say that the vector table address is a multiple of the vector table size, rounded up to a power of 2. Since the ST Cortex-M4 and Cortex-M7 processors implement 65-128 interrupts, the interrupt vector table is 128 words or 512 bytes long. This means that bits 8-0 must be zero, leading to the following more complete description, as used in the ST Cortex-M4 manual:

- bits 31-30 are reserved/zero

- bits 29-9 contain the vector table address bits 29-9

- bits 8-0 must be zero

ARM ARMv7-M Architecture Reference Manual, section B3.2.5 'Vector Table Offset Register, VTOR'

This description is incomplete. The section shows the VTOR register contains:

- bits 31-7 contain the vector table address bits 31-7

- bits 6-0 are reserved

The ARM manual states that bits 31-30 may be implemented as zero (RAZ/WI).

The effect of this is that the VTOR register contains the vector table starting address, which must be a multiple of 128 bytes. This is consistent with the ARM pseudo-code in section B1.5.6 'Exception entry behavior', which shows under 'ExceptionTaken(integer ExceptionNumber)' the calculation of the vector address. That calculation adds (not ors) the scaled exception number to the vector table address, implying no restriction on the vector table address beyond that bits 6-0 must be zero.

The ARMv7-M Architecture Reference Manual fails to state that the vector table address must be a multiple of the vector table size (rounded up to an integer power of 2).

[Tesla DeLorean]

Posted on November 09, 2017 at 00:22

>>

The ARMv7-M Architecture Reference Manual fails to state that the vector table address must be a multiple of the vector table size (rounded up to an integer power of 2).

That's my understanding, the exact number of low order bits required to be zero depends on the vendors implementation, driving the number of vectors held in the NVIC, and in the table. The NVIC can be built to support up to 240 external interrupt sources, along with the 16 system handlers, which gets you to 256 total. This would mean the biggest supported table and alignment would be 1024 bytes.

[dbrown]

Posted on November 09, 2017 at 00:33

Clive,

Thank you. You are correct, my explanation of the ST Cortex-M4 and Cortex-M7 interrupt vector table alignment is wrong.

For the ST Cortex-M7, PM0253 section 4.2 states that the NVIC supports up to 240 interrupts, so the interrupt vector table may need 1024 byte alignment.

For the ST Cortex-M4, PM0214 section 4.3 states that the NVIC supports up to 81 interrupts, so the interrupt vector table may need 512 byte alignment.

The actual number of interrupts supported by the NVIC is device-dependent, here are a few numbers I pulled out from the relevant datasheets:

STM32F765/7/8A/9: 126 interrupts (110 plus 16), requiring 512 byte alignment

STM32L433, STM32L452: 83 interrupts (67+16), requiring 512 byte alignment