topic Re: Issue Writing to Vector Table on KE/KEA in Kinetis Microcontrollers

Issue Writing to Vector Table on KE/KEA

tomsparks — Sat, 30 May 2020 21:56:16 GMT

DEVICE: KE06/KEA128 (two examples of each were tested)

To begin, I checked the value of VTOR and it reported the value of '0' for the offset. I took this to mean the table is not offset. So I attempted to load the address value of my IRQ handler routine into that table location. During execution It faulted on that assignment statement into the "DefaultISR," which is simply a loop found in "startup_SKEAZ1284.S."

Here are some of the relevant code bits:

...

...
// "Tag" of IRQ pointer assigned to the IRQ address. '0xA0' is the mem. loc. of IRQ 24:
#define  KBI0_IRQ  (  * ( volatile uint32_t * ) 0x000000A0 ) 
...

// Handler defined:
void __attribute__  ((interrupt)) Handler_IRQ (void) {...}
...
int main(){...
...

// Assignment and fault site:
KBI0_IRQ = (uint32_t)&Handler_IRQ;
 
// Also tried...
KBI0_IRQ = (uint32_t)Handler_IRQ;

// Neither worked, both faulted
...‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

It was my impression the vector table was part of code space and not privileged, however I could be wrong. Is there a write protection or boundary issue I'm not aware of? Is this a little/big endian issue? I also tried to write before and after enabling both the KBI module and the NVIC. Thank you for any light you can shed on this situation.

Thanks again,
Tom

Re: Issue Writing to Vector Table on KE/KEA

mjbcswitzerland — Sun, 31 May 2020 13:13:34 GMT

Tom

0x00000000 (default VTOR) is in Flash and you can't copy vectors to flash without using flashing routines.

In addition one would not normally write vectors to this area during run time because it could only be done once and need a sector erase to write again (extremely dangerous during operation because the complete sector needs to be backed up and re-flashed and any power cycle during the procedure would leaves the device in an un-bootable state).

The technique used when vectors are to be inserted at run time is to relocate to SRAM where they can be loaded and changed at will - just set the VTOR to match the SRAM location, which should be on a 256 byte aligned boundary for your devices (or a 512 byte aligned boundary generally so that also larger vector tables could be supported). Generally the start of SRAM is convenient.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

Re: Issue Writing to Vector Table on KE/KEA

tomsparks — Sun, 31 May 2020 18:06:44 GMT

Thank you, Mark. I've been reading a lot about relocating the table and now I understand why that's important.

Thanks again,

Tom