Flashloader inside application

[DanielePagani]

   Dear sirs,

we're working with i.MX RT1060 EVK board and we're wondering about best practices for In-Application Programming.

We can correctly use Sdphost and Blhost utility, according to: Flash loader i.MXRT1060https://cache.nxp.com/secured/assets/downloads/en/programmers/FLASHLOADER-RT106x-1-GA.zip?__gda__=15...

However, we can not use boot pin mode for hardware's constraints.

So, we're using Rom Apis to set device programmatically into serial download mode:

void bl_serial_downloader(void)

{

run_bootloader_ctx_t boot_para;

boot_para.B.imageIndex = 0;

boot_para.B.serialBootInterface = kEnterBootloader_SerialInterface_USB;

boot_para.B.bootMode = kEnterBootloader_Mode_SerialDownloader;

boot_para.B.tag = kEnterBootloader_Tag;

g_bootloaderTree->runBootloader( (void *)&boot_para );

}

However, according to ROM APIs this feature is not available for all i.MX RT processors and our project can require usage of other processors.

So, we guess to load Flashloader application inside main application and then run it if required.

We define an array flashloader of bytes with Flashloader bin file and then we call a jump to application:

 .data.flashloader

                0x0000000020000000    0x161a1 ./source/led_blinky.o

                0x0000000020000000                flashloader

 *fill*         0x00000000200161a1        0x3 ff

JumpApplication(*(uint32_t*)0x20000400, *(uint32_t*)0x20000404);

__STATIC_FORCEINLINE void JumpApplication(uint32_t topOfMainStack, uint32_t AppAddr)

{

    __ASM volatile ("mov SP, %0" : : "r" (topOfMainStack) : );

    __ASM volatile ("mov PC, %0" : : "r" (AppAddr) : );

}

This solution doesn't work, so, can you suggest something about the matter?

BR,

Daniele

[jeremyzhou]

Hi Daniele Pagani,

Thanks for your reply.

The ivt_flashloader.bin file is from  Flash loader i.MXRT 1060 (\Flashloader_RT106x_1.0_GA\Tools\mfgtools-rel\Profiles\MXRT106X\OS Firmware).

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.
-------------------------------------------------------------------------------

[DanielePagani]

    Hi jeremyzhou‌,

we have again performed all the steps shown in the thread Generating a Bootable Image for the RT1050, because we think we are making some mistakes using MCUXpresso (to export .s19 file) and elftosb (to generate .bin file).

We've a doubt about the step "Bootable Image Generation - SRAM".

It seems that the memory allocation in the memory configuration MCU Settings must be set to 0x20000000 for SRAM_DTC, but, using this value, elftosb command output is a Segmentation fault 11.

So, we've to set that value to 0x20002000.

The offset of 0x2000 is similar to "Bootable Image Generation - SDRAM" (document reports address 0x80002000) and "Bootable Image Generation - XiP HyperFlash" (address 0x60002000).

Is 0x20000000 address a mistake (instead of 0x20002000)?

BR 

Daniele

[jeremyzhou]

Hi Daniele Pagani,

Thanks for your reply.

1) Is 0x20000000 address a mistake (instead of 0x20002000)?
-- In my opinion, I don't think so, however, you can give a try.

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.
-------------------------------------------------------------------------------

[DanielePagani]

    Hi jeremyzhou‌,

first of all we thank you for the valuable support.

According to Question about creating bootable image for FlexSPINOR XIP for IMXRT1052 (again), it seems that it is mandatory leave room of 0x2000 for Image Vector Table Offset and Boot Data.

Anyhow, we tried with start address 0x20000000 and elftosb doesn't work fine.

On Mac, it returns a Segmentation Fault 11.

On Pc, it creates and empty (0 bytes) .bin file.

Can you kindly let us understand the matter or indicate further documentation?

Then, as far as XIP_BOOT_HEADER_ENABLE and XIP_BOOT_HEADER_DCD_ENABLE preprocessor options referred by Generating a Bootable Image for the RT1050, reading linker script template (MCUXpresso directory installation/Wizards/linker/), it seems that if the Flash start address is not 0x60000000, then boot header is not created:

- boot_hdr_MIMXRT1060.ldt -

<#-- Only insert header if Flash region starts at true base address -->
<#if (MemUtils.location(CODE) == Utils.strToInt("0x60000000")) || (MemUtils.location(CODE) == Utils.strToInt("0x70000000")) >
/* Image Vector Table and Boot Data for booting from external flash */
.boot_hdr : ALIGN(${text_align})
{
FILL(0xff)
__boot_hdr_start__ = ABSOLUTE(.) ;
KEEP(*(.boot_hdr.conf))
. = 0x1000 ;
KEEP(*(.boot_hdr.ivt))
. = 0x1020 ;
KEEP(*(.boot_hdr.boot_data))
. = 0x1030 ;
KEEP(*(.boot_hdr.dcd_data))
__boot_hdr_end__ = ABSOLUTE(.) ;
. = 0x2000 ;
} >${CODE}

</#if>

Does the linker script have priority over preprocessor directives?

Finally, we do not have clear the advantages of using the elftosb utility for creating the binary file compared to the binary utilities offered by MCUXpresso. Does it have additional features that MCUXpresso does not offer?

BR

Daniele

[jackking]

We found that the Mac version of elftosb for the i.mxrt isn’t really usable at this point.  Switching to Windows version to run elftosb worked as expected.

[jeremyzhou]

Hi Daniele Pagani ,

Thanks for your reply.
1) Is it correct?
-- Yes, it's.
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.
-------------------------------------------------------------------------------