Issue Writing to Vector Table on KE/KEA

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Issue Writing to Vector Table on KE/KEA

跳至解决方案
1,124 次查看
tomsparks
Contributor III

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

0 项奖励
1 解答
1,020 次查看
tomsparks
Contributor III

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

Thanks again,

Tom

在原帖中查看解决方案

0 项奖励
2 回复数
1,020 次查看
mjbcswitzerland
Specialist V

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]

1,021 次查看
tomsparks
Contributor III

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

Thanks again,

Tom

0 项奖励