just like the info from
Our environment is MCUXpresso v11.0.1 + SDK2.6.1.
I guess it won't help because application image had chosen 'Link Application to RAM', which will not generate FCB / IVT /DCD header in generate binary file and re-initialize SDRAM via DCD area.
Hi WEI-TA CHEN,
Thank you for your interest in NXP Semiconductor products and the opportunity to serve you.
1. For application image, should we remove XIP_BOOT_HEADER_ENABLE and XIP_BOOT_HEADER_DCD_ENABLE?
-- Yes, please refer to the Generating a Bootable Image for the RT1050 to generate the binary file of the application project.
2. For the sample code of jumpApplication in the bootloader, should we disable Cache and IRQ before assigning SDRAM_ADDRESS to SCB->VTOR?
-- It's not necessary to disable Cache and IRQ, I'd like to suggest you refer to the flashloader demo project in the SDK library to learn the preparation work before jumping to application.
1. After adjusting SDRAM offset from 0x80000000 to 0x80002000, the elftosb works and could generate binary files (padding / nopadding).
2. We don't think the NXP flashloader is what we desired in multiple application images arch.
However, we have tried to load raw binary file (Generate via MCUXPresso) or bootable image (via elftosb with RT1020 DCD.bin file) to SDRAM.
Both image does not work in below code example:
static void jump_to_user_application(uint32_t app_start)
/* Relocate vector table */
SCB->VTOR = app_start;
jump(*(uint32_t *)(app_start), *((uint32_t *)(app_start+4)));
/** Jump to application */
static void jump(uint32_t user_sp, uint32_t user_startup)
static void (*farewell_bootloader)(void) = 0;
farewell_bootloader = (void (*)(void))user_startup;
// Set stack pointers to the application stack pointer.
// Jump to the application.
We thought the resetISR address and isr_vector address are correct after check with map file.
Could SDRAM be execute in raw binary format in arch we expected? Or bootable Image format is needed?
Another question is about SKIP_SYSCLK_INIT, according to the comment in clock_config.c, it seems will effect image executing in SDRAM.
Thanks in advance.
Hi WEI-TA CHEN,
Thanks for your reply.
1) Could SDRAM be executed in raw binary format in arch we expected? Or bootable Image format is needed?
-- Yes, in the SDRAM, the raw binary image is able to be run.
I was wondering if you can introduce the steps of programming the APP1 and APP2 to the QSPI in detais, as I don't find some obvious error in the jump_to_user_application() function.
thanks for your response, I will list my sample code as attachment for your information. (MIMXRT1021_FW.c)
Our procedure is quite simple:
1. Generate application raw binary via MCUXPresso binary utility
2. Program our bootloader as XIP bootable image into 0x6000_0000. (bootloader binary size : 107KBytes)
3. Program application binary file into 0x6020_0000 as APP1 and our boot config database (MAGICWORD) at 0x607FE000.
-The boot config database seems not the root cause for our issue, therefore I skip the detail here.
4. copy default APP1 image to SDRAM address 0x8000_0000, and memcmp the content of SDRAM with correct file size.
memcpy((void *)APP_SDRAM_ADDRESS, (void *)imageStartAddress, imageLength);
For application image, please download or refer to the evkmimxrt1020_iled_blinky.rar from Kerry Chou as example at NXP link :
It's a quite simple sample and can't work in our procedure of bootloader now.
With check SDRAM info via debugger, the application image content and size are correct after memcpy.
thanks for your kindly helps.
Yes, you are correct about the IRQ and Cache operation in bootloader => No need to disable it.
However, like the info you provide in bootable application image, we met elftosb crash probelm:
"Unfortunately elftosb crashes when I attempt to create the binaries. It keeps looking for "section 0x0", although the addresses in the S19 file are correct. This happens both with SDRAM and internal RAM version."
We guess maybe there is something related to flash operation need to revise in our application environment to avoid untouchable area, would you please give us some suggestion about elftosb crash problem?
There are some info related to our environment: