Vector Table Offset - is this exected behaviour??

[mjbcswitzerland]

Hi All

Usually I work with interrupt vectors in SRAM but recently I have had the need to have then fixed in Flash and during some work with this the following effect was observed:

1. K20DX256(72MHz) with a few interrupt operating but two of them are used to explain. One is the USB interrupt at vector 89 (counting from 0 being the stack pointer vector) and the other is the UART0 status interrupt at vector 61.

If the vectors are fixed in Flash at the start (0x00000000) these vector locations are physicaly at:

- USB - 4 x 89 = 0x164

- UART0 - 4 x 61 = 0xf4

This is standard and works as expected.

2. Now I link the vectors to 0x8000 instead and set the vector table offset (VTOR) in the Cortex to 0x8000 and the vectors are now physically at

- USB 0x8164

- UART0 0x80f4

Again all works as expected.

3. Now I link to 0x8080 (noting that the vector table offset register has its lower 7 bits unimplemented, so this is the next highest location possible) and the vectors are physically at

- USB 0x81e4

- UART0 0x8174

In this case the USB operates normally but as soon as there is a UART0 interrupt there is an undefined interrupt exception and it turns out that it is vector 29 (DMA channel 13) that unexpectedly interrupts, although there is no DMA operatung and its interrupts are all disabled. This vector would be physially at 0x80f4, which matches the UART0 vector if the vector table were still at 0x8000.....

So, for fun, the UART0 vector is set to the DMA channel 13 vector location and all starts working completely again.

This suggests therefore that some interrupt vectors are moved by the vector table offset value of 0x8080 by 0x8080 (eg, the USB vector which is at 0x00000164 is shifted by 0x8080 to 0x000081e4 (as expected) but some are not - eg. UART0, which is at 0x000000f4 is not shifted by 0x8080 to 0x00008174 (as expected) but instead only shfted by 0x8000 to 0x000080f4.

Expresed in a different way, the vector table offset is not behaving as the same offset for all vectors.

For the USB vector it is + 0x8080 but for the UAR0 vector it is only + 0x8000. [or it is implemented as | 0x8080 and not + 0x8080]

Therefore the question - is this expected or is something wrong??

Regards

Mark

[frankbösing · Accepted solution]

Read the manual.

ARM Information Center

You need to use the correct alignment as described in the document.

[mjbcswitzerland]

Frank

Thank you for the clarification. I have been using the "ARM®v7-M Architecture Reference Manual" where this detail is not mentioned.

Now it is clear that the 0x200 boundary, as found from experimentation, is the expected limitation for this device (due to its number of interrupts) and that it changes depending on the number of interrupts available.

Also the reference states "See your vendor documentation for the alignment details of your device", but this detail was not found there either.

In future I will use the on-line reference which looks to be superior.

Regards

Mark

[mjbcswitzerland]

Hi

Curiosity got the better of me and I tried locating the vectors at 0x8100. The result was that the USB interrupt now stopped working correcty - and fired as dma chnanel 9 vector - while the UART0 worked normally.

This adds the following set of results:

4. Now I link to 0x8100

- USB 0x8264

- UART0 0x81f4

In this case the UART0operates normally but as soon as there is a USB interrupt there is an undefined interrupt exception and it turns out that it is vector 25 (DMA channel 9) that unexpectedly interrupts, although there is no DMA operatung and its interrupts are all disabled. This vector would be physically at 0x8164, which matches the USB vector if the vector table were still at 0x8000.....

With these two cases the conclusion is now becoming quite clear:

For VTOR 0x8080

For the USB vector it is + 0x8080 but for the UAR0 vector it is only + 0x8000. [or it is implemented as | 0x8080 and not + 0x8080]

For VTOR 0x8100

For the UART vector it is + 0x8100 but for the USD vector it is only + 0x8000. [or it is implemented as | 0x8100 and not + 0x8100]

This suggests that the VTOR is not operating as an address offset but as an address OR.

For the K20 in question, with 111 vector entries, it means that the next vector offset that can be used after 0x8000 is 0x8200, or generally it has a resolution of 0x200 and not 0x80 as the VTOR does.

Reading ARM's description of VTOR it looks as though this should operate as an offset and ARM recommends writing 0xffffffff to the register and reading back to see how many bits are actually implemented. Doing this return 0xffffff80 as expected.

Can anyone say whether this behaviour is in fact normal or whether the implementation is unusual?

Regards

Mark

[yasuhikokoumoto]

Hi Mark,

I investigated the V850E2, SuperH2 and ColdFire implementations and found an interrupt vector was calculated by adding (not or-ing) vector offset to the Vector Base Address in all three CPU cases. I think the lower bits of VTOR must be fixed to '0' properly according to the number of interrupts by Kinetis implementation as that all vector addresses become equivalent whether they are made by adding or or-ing.

Best regards,

Yasuhiko Koumoto.

[yasuhikokoumoto]

Hi Mark,

it's a very interesting experiment. It is new information that the vector is calculated by ORed with VTOR. However, I don't know whether it would be normal.

Best regards,
Yasuhiko Koumoto.