Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 7 of 7

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

  1. #1
    Senior Member
    Join Date
    Mar 2014
    Location
    Switzerland
    Posts
    115

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

    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

  2. #2
    Senior Member
    Join Date
    Mar 2014
    Location
    Switzerland
    Posts
    115
    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

  3. #3
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,267
    Quote Originally Posted by uTasker View Post
    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).

    Quote Originally Posted by uTasker View Post
    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 by Frank B; 06-25-2021 at 06:26 AM.

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,028
    Quote Originally Posted by uTasker View Post
    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.

  5. #5
    Senior Member
    Join Date
    Mar 2014
    Location
    Switzerland
    Posts
    115
    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

  6. #6
    Senior Member
    Join Date
    Mar 2014
    Location
    Switzerland
    Posts
    115
    Quote Originally Posted by PaulStoffregen View Post
    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

  7. #7
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,267
    Often, pretty much reading between the lines..

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •