vector table

[ostheim]

Posted on May 01, 2008 at 05:49

vector table

[ostheim]

Posted on May 17, 2011 at 12:34

Hello!

I'm trying to understand some details concerning the vector table which are puzzling me. What I've got so far: cortex technical reference:

Quote:

Interrupt Controller Type Register: Read the Interrupt Controller Type Register to see the number of interrupt lines that the NVIC supports. ... The NVIC supports up to 240 dynamically reprioritizable interrupts... Well this register gives the number of available interrupt lines in chunks of 32 lines. reference manual:

Quote:

â—� 43 maskable interrupt channels (not including the 16 interrupt lines of Cortexâ„¢-M3) The vector table holds 43 + 12 additional vectors (not counting the reserved stack definition value). My conclusion: There seem to be (up to) 16 (internal) Cortex interrupt lines. The information register gives the number of lines including these 16 cortex lines (which seems to make sense to me in conjunction with the maximum of 240 available lines) The STM32 either implements only 12 of the cortex lines or some of the lines don't need a value in the table. Reading the information register while debugging gives a value of 1 - which says 33..64 lines. Does anyone know this is true so far? The reason for all this: I want to design a model independent bootloader and for various reasons I'd like to know if it's possible to predict the maximum size of the vector table by reading the the information register. Another Problem: There seems to me some inconsistency with the vector table offset value: cortex technical reference:

Quote:

When setting a position, the offset must be aligned based on the number of exceptions in the table. This means that the minimal alignment is 32 words that you can use for up to 16 interrupts. For more interrupts, you must adjust the alignment by rounding up to the next power of two. For example, if you require 21 interrupts, the alignment must be on a 64-word boundary because table size is 37 words, next power of two is 64. Well, there seems to be something wrong: how can be the minimum alignment be 32 words (or 64 bytes) when on the other hand the lowest 7 bits are reserved (and have to be 0) - if I count correct that would afford a minimum alignment of 128 bytes, wouldn't it? It seems that 16 interrupts need a table of 64 bytes - that makes 4 bytes per vector ;) So far so good - but how do they count in the second example: 21 interrupts need a table of 37 words? :o Well, this doesn't make sense to me - but 21 free interrupts plus 16 cortex interrupts would make 37 interrupts - for these I would count 148 bytes for the table .... leading to an alignment of 256 bytes... Ok if I count this way 16 free interrupts plus 16 internal makes 32 interrupts - this gives 128 bytes for the table - and this would fit with the 7 reserved bits forcing the minimum alignment for 32 vectors (the maximum of the first range of interrupts (1..32)). But these are only my assumptions, who knows for sure? Well, if you look at NVIC_SetVectorTable in the firmware lib it seems the programmers weren't sure too on this topic:

Quote:

* - Offset: Vector Table base offset field. * This value must be a multiple of 0x100. ... SCB->VTOR = NVIC_VectTab | (Offset & (u32)0x1FFFFF80); As you see the comment says there must be an alingment of 256 byte for the offset, the masking operation fails to so. Since the STM32 is in the range of 33..64 interrupts. Am I the only one who is seeing here some obscurities?

[lanchon]

Posted on May 17, 2011 at 12:34

the stm32 vector table has 16 (cortex) + 43 (non-core) vectors. of the 16 cortex vectors (numbered 0 to 15 and present on all cortex cores), some are reserved or have a special function like __cs3_stack:

__cs3_interrupt_vector_lanchon_stm32: .long __cs3_stack .long __cs3_reset .long NMIException .long HardFaultException .long MemManageException .long BusFaultException .long UsageFaultException .long __STM32ReservedException7 .long __STM32ReservedException8 .long __STM32ReservedException9 .long __STM32ReservedException10 .long SVCHandler .long DebugMonitor .long __STM32ReservedException13 .long PendSVC .long SysTickHandler .long WWDG_IRQHandler .long PVD_IRQHandler .long TAMPER_IRQHandler ... vectors 16 to 58 are non-core. > Well, there seems to be something wrong: how can be the minimum alignment be 32 words (or 64 bytes) when on the other hand the lowest 7 bits are reserved (and have to be 0) - if I count correct that would afford a minimum alignment of 128 bytes, wouldn't it? nothing wrong, 32 words are 128 bytes. and in the stm32, I'd guess that the lowest 8 bits (and not just 7) are reserved (ie: not implemented and fixed at zero). > There seems to me some inconsistency with the vector table offset value no inconsistency: When setting a position, the offset must be aligned based on the number of exceptions in the table. This means that the minimal alignment is 32 words that you can use for up to 16 interrupts. - [16 non-core interrupts + 16 core vectors correspond to the minimal vector table alignment of 32 words.] For more interrupts, you must adjust the alignment by rounding up to the next power of two. For example, if you require 21 interrupts, the alignment must be on a 64-word boundary because table size is 37 words, next power of two is 64. - [21 non-core + 16 core gives 37 vectors requiring 64 word alignment.] > * - Offset: Vector Table base offset field. * This value must be a multiple of 0x100. the comment is clear and correct. > the comment says there must be an alingment of 256 byte for the offset, the masking operation fails to so. > SCB->VTOR = NVIC_VectTab | (Offset & (u32)0x1FFFFF80); masking is *not* a solution to the alignment problem. if the vector table is unaligned, masking does not provide any benefits. on the subject of why the masking is there you can only ask the programmer. I suspect they have the custom of always masking the bit-field they are accessing, or the infrastructure to do that automatically, or maybe they are pressured to do that by the architect, who knows.

[ostheim]

Posted on May 17, 2011 at 12:34

Hi Lanchon!

Thanks for making some things clearer for me. :D I've missed that there were some reserved vectors in one line of the table - so there are no cortex vectors missing as the stack information counts as vector too. >nothing wrong, 32 words are 128 bytes. and in the stm32, I'd guess that the lowest 8 bits (and not just 7) are reserved (ie: not implemented and fixed at zero). Well, if there are people out there who count words with 4 bytes that makes the computation correct again - (I wasn't aware of this as I would name these dwords or longs). There are really only 7 bits reserved cortex technical reference:

Quote:

Vector Table Offset Register bit assignments: Bits Field Function [31:30] - Reserved [29] TBLBASE Table base is in Code (0) or RAM (1) [28:7] TBLOFF Vector table base offset field. Contains the offset of the table base from the bottom of the SRAM or CODE space. [6:0] - Reserved. So they count the table length as I've worked it out :) But there is still a ''missing link'' for me: When they speak of (non core) interrupts in the table - is this the number of available interrupts (ie. 43 for the current stm32) (this would be a a hardware specific value) or the highest vector number of the actually used vectors if one would omit the last unused vectors in the table (which I personally wouldn't encourage to do) (this would be a software-specific value) I think the first variant makes more sense - but I didn't find it clearly written. This would also make minimum alignment of the vector table a hardware specific issue. >masking is *not* a solution to the alignment problem. if the vector table is unaligned, masking does not provide any benefits. That's true, the masking wouldn't correct an alignment fault - it should be possibly checked in the debugfunction IS_NVIC_OFFSET Well, it seems the content of Interrupt Controller Type Register (which seems to be not supported by the current firmware lib - or have I missed the get-function for this register?) gives the maximum count of interrupt vectors (including the 16 corex ones) (i.e.: 32,64,96...). This might also give the maximum length of the vector table and the minimum alignment for the table (if this value is hardware specific as I assume)

[lanchon]

Posted on May 17, 2011 at 12:34

> if there are people out there who count words with 4 bytes

for all ARM related literature: word: 32 bits half-word: 16 bits for all architectures: word is supposed to stand for the ''natural'' data size (16 bits in the 8086). > There are really only 7 bits reserved that bit assignment table comes from the cortex manual. the cortex is a customizable core. the table shows the ''worst case'' bit assignment, but also says the the value has to be aligned. so for the stm32 they show a bit 7 but they say that it *must* be zero. is it really there? I doubt it. on the stm32 that bit is probably not implemented and read as zero. (if you want try writing 0x80 and you'll probably read back 0.) on the stm32 a vector address is made by concatenating: 24 high bits from the offset register, 6 bits from the vector number, and two zero bits. the alignment requirement is there to obviate the need for an adder. > (this would be a a hardware specific value) or the highest vector number of the actually used vectors a hardware specific value, the value selected for that configuration option when the core was synthesized. (no matter how you use the stm32, there probably isn't a bit7 to configure anyway; alignment *will be* 64 words, it's in the architecture, there's no adder.) > That's true, the masking wouldn't correct an alignment fault it's not an alignment fault, it's a fetch of an incorrect vector. data you try to program in bits 7 to 0 goes to limbo; bits 7 to 0 are non-implemented implicit zeros. > Interrupt Controller Type Register [...] gives the maximum count of interrupt vectors (including the 16 corex ones) (i.e.: 32,64,96...). This might also give the maximum length of the vector table and the minimum alignment for the table I don't know that register. but if 96 is a possible value (I mean interpretation) for it then it's definitely not the minimum vector table alignment, it's only the table size.