Teensy 4 ImageVectorTable[] not matching the NXP format (?)

Status
Not open for further replies.

uTasker

Well-known member
Hi

I just noticed that the ImageVectorTable[] as used in the Teensy project doesn't match with that used by NXP.

__attribute__ ((section(".ivt"), used))
const uint32_t ImageVectorTable[8] = {
0x432000D1, // header
(uint32_t)&ResetHandler,// program entry
0, // reserved
0, // dcd
(uint32_t)BootData, // abs address of boot data
(uint32_t)ImageVectorTable, // self
(uint32_t)hab_csf, // command sequence file
0 // reserved
};

where ResetHandler is the address of the routine void ResetHandler(void).


NXP does it differently:

__attribute__ ((section(".ivt"), used))
const uint32_t ImageVectorTable[8] = {
0x412000D1, // header
(uint32_t)__Vectors,// program entry
0, // reserved
0, // dcd
(uint32_t)BootData, // abs address of boot data
(uint32_t)ImageVectorTable, // self
(uint32_t)hab_csf, // command sequence file
0 // reserved
};

where

void (* const g_pfnVectors[])(void) = {
// Core Level - CM7
&_vStackTop, // The initial stack pointer
ResetISR, // The reset handler
...

and

ResetISR is the reset handler equivalent to void ResetHandler(void).


This means that when the ROM LOADER jumps to the reset handler it first sets the stack pointer with the first entry and the second entry is used as the entry point.

How does it work with the Teensy method which doesn't conform to this, and how is the stack pointer set in the Teensy 4 project?

Regards

Mark
 
All

Another note. The IVT version number is set to 0x43, whereas i have seen only 0x40 and 0x41 used before.
NXP doesn't seem to know anything about a 0x43 version.

Anyone know where this comes from?

I have however found that the ROM LOADER will consider an odd access to be a direct jump value and an even one to be a reset vectors address and so handles the two types accordingly. This is not documented but was also found out by someone at NXP who then had access to the ROM loader code and found the same decision being made. The question remains though as to how the stack pointer is being controlled when a reset vectors is not used?

Regards

Mark
 
I have however found that the ROM LOADER will consider an odd access to be a direct jump value and an even one to be a reset vectors address and so handles the two types accordingly
I think this is to maintain compatibility with older chips (without bootloader).

The question remains though as to how the stack pointer is being controlled when a reset vectors is not used?
Line 64: https://github.com/PaulStoffregen/cores/blob/master/teensy4/startup.c#L64


 
Last edited:
NXP doesn't seem to know anything about a 0x43 version.

Well, that depends on which NXP you ask. If you call hab_rvt.get_version(), it'll tell you version 4.3.7 (or at least a 32 bit number you can interpret / guess to mean 4.3.7).

And yeah, their documentation is incomplete, outdated, inconsistent, and riddled with errors.
 
Thanks!
The editor I used to open the file was hiding this line since it is in a conditional define but now I see it just after setting the FlexRAM configuration.
I see that the FlexRAM is allocated to ITC and DTC without any OCRAM - which I find good.

Regards
Mark
 
Well, that depends on which NXP you ask. If you call hab_rvt.get_version(), it'll tell you version 4.3.7 (or at least a 32 bit number you can interpret / guess to mean 4.3.7).

And yeah, their documentation is incomplete, outdated, inconsistent, and riddled with errors.

Thanks - maybe NXP is torn between keeping as much as possible secret but giving just enough information for it to be used with a little reading-between-the-lines and some trial and error.

Regards

Mark
 
Status
Not open for further replies.
Back
Top