Hi
I only just noticed that the NXP Image Vector Table documentation:
doesn't match the NXP code:
/*************************************
* IVT Data
*************************************/
const ivt image_vector_table = {
IVT_HEADER, /* IVT Header */
IMAGE_ENTRY_ADDRESS, /* Image Entry Function */
IVT_RSVD, /* Reserved = 0 */
(uint32_t)DCD_ADDRESS, /* Address where DCD information is stored */
(uint32_t)BOOT_DATA_ADDRESS, /* Address where BOOT Data Structure is stored */
(uint32_t)&image_vector_table, /* Pointer to IVT Self (absolute address */
(uint32_t)CSF_ADDRESS, /* Address where CSF file is stored */
IVT_RSVD /* Reserved = 0 */
};
where
#define IMAGE_ENTRY_ADDRESS ((uint32_t)__Vectors)
and so
__attribute__ ((used, section(".isr_vector")))
void (* const g_pfnVectors[])(void) = {
// Core Level - CM7
&_vStackTop, // The initial stack pointer
ResetISR, // The reset handler
...
...
meaning that the documentation shows the image entry to be a pointer to the initial instruction to be executed. Also:
But the SDK used a pointer to the reset vector, which starts with the stack pointer value.
The SDK uses a header version number of 0x41
I have seen other project that uses a header version number of 0x43 and a real pointer to the program entry instruction.
Does this means that the version number can control different behaviors or does the ROM LOADER actually identify which type it is? Why does the SDK not follow the details described in the documentation and is there an explanation of such nuances?
Regards
Mark
解決済! 解決策の投稿を見る。
Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1) Does this means that the version number can control different behaviors or does the ROM LOADER actually identify which type it is?
-- Yes, I once wrote an article to introduce it, however, it's written in Chinese and you may need Google Translate's help.
2) Why does the SDK not follow the details described in the documentation and is there an explanation of such nuances?
-- I'll report your advice to the Document team later.
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1) Does this means that the version number can control different behaviors or does the ROM LOADER actually identify which type it is?
-- Yes, I once wrote an article to introduce it, however, it's written in Chinese and you may need Google Translate's help.
2) Why does the SDK not follow the details described in the documentation and is there an explanation of such nuances?
-- I'll report your advice to the Document team later.
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi
Many thanks for that - it is a very good article and explains the differences I am seeing.
Initially I thought that the version number was being used to control the operation but according to the code that you show it is simply whether the address is aligned or no - if aligned it is treated as a reset vector entry and if not aligned as an absolute entry address.
I see that in one case you have the version number set to 0x40 and in another set to 0x41. I have also seen 0x43 being used. Is there an explanation for these differences?
Regards
Mark
Hi,
Thanks for your reply.
1) Is there an explanation for these differences?
-- Until now, no, and can you share with me an IVT table whose header is 0x43?
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi
I was testing a project that was developed with the Teensy 4 framework, where I identified that the image vector table was not as I have ever seen it before (it was causing the uTasker boot loader to question its validity).
So I looked at the code in its repository at https://github.com/PaulStoffregen/cores/tree/master/teensy4
and in the file bootdata.c I find:
__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 the version is set to 0x43 - this made me think that there was possibly something special about the boot loader revision which changed its behavior.
I have asked at the Teensy forum whether anyone knows about this.
Regards
Mark