Issue Writing to Vector Table on KE/KEA

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Issue Writing to Vector Table on KE/KEA

ソリューションへジャンプ
1,995件の閲覧回数
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,891件の閲覧回数
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,891件の閲覧回数
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,892件の閲覧回数
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 件の賞賛
返信