iMX RT102xEVB : Failed to run the application From SDRAM via QSPI XIP

ithinkchen926 · ‎09-27-2019

Dear all,

just like the info from

iMX RT105x : Running the Application From SDRAM

Our environment is MCUXpresso v11.0.1 + SDK2.6.1.

We have created a simple bootloader running in XIP QSPI flash (0x60000000) and this bootloader copies the application image sits in QSPI to the external SDRAM (0x80000000).

The SDRAM is initialized by DCD (evkmimxrt1020_sdram_ini_dcd.c) when loader runs in QSPI.

(SKIP_SYSCLK_INIT
XIP_EXTERNAL_FLASH=1
XIP_BOOT_HEADER_ENABLE=1
XIP_BOOT_HEADER_DCD_ENABLE=1/ ... etc)

The applicatoin image is built for SDRAM which refer to build procedure as below and it works if we only executed it in SDRAM to instead of copy the application image via QSPI loader.

(SKIP_SYSCLK_INIT
XIP_EXTERNAL_FLASH=1
XIP_BOOT_HEADER_ENABLE=1
XIP_BOOT_HEADER_DCD_ENABLE=1/ ... etc)

Then choose 'Link Application to RAM' in 'Managed Linker Script'.

However, we still met the similar problem 'PRECISERR Bus Fault.' with below sample code:

#define QSPI_IMAGE_ADDRESS 0x60300000

#define SDRAM_ADDRESS 0x80000000

memcpy((void*)SDRAM_ADDRESS,(void*)(JUMP_ADDRESS),binary_file_size); // .bin size

SCB->VTOR = (uint32_t)(SDRAM_ADDRESS);

JumpApplication(*(uint32_t*)(SDRAM_ADDRESS), *(uint32_t*)(SDRAM_ADDRESS+4));

After comparing the ResetISR address in .map file, application binary info and dump info of SDRAM_ADDRESS via CMSIS DAP on baord debugger, we still can't find obvious error info or clues for the SDRAM executed failed problem.

Does anyone can help to provide or check below info maybe a correct debug direction?

1. For application image, should we remove XIP_BOOT_HEADER_ENABLE and XIP_BOOT_HEADER_DCD_ENABLE?

The remain preprocessor options will be:

SKIP_SYSCLK_INIT
XIP_EXTERNAL_FLASH=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.

2. For the sample code of jumpApplication in bootloader, should we disable Cache and IRQ before assign SDRAM_ADDRESS to SCB->VTOR?

DisableGlobalIRQ();

SCB_DisableDCache();

SCB_DisableICache();

SCB->VTOR = (uint32_t)(SDRAM_ADDRESS);

Does anyone know what am I missing?

Thanks in advance.

Wed.

ithinkchen926 · ‎10-07-2019

Dear all,

the problem is fixed after adding SDRAM noncacheable area in application and Cache Disable in bootloader.

SCB_DisableDCache();

SCB_DisableICache();

Anyway, RT10xx series cross-over processor could support the basic arch we provided.

Thanks again:)

jeremyzhou · ‎09-29-2019

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.

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

ithinkchen926 · ‎10-02-2019

Dear Jeremy,

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.
__set_MSP(user_sp);
__set_PSP(user_sp);

// Jump to the application.
farewell_bootloader();
}

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.

jeremyzhou · ‎10-03-2019

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.

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

ithinkchen926 · ‎10-04-2019

Dear jeremyzhou,

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);

5. jump_to_user_application((uint32_t)(APP_SDRAM_ADDRESS));

For application image, please download or refer to the evkmimxrt1020_iled_blinky.rar from Kerry Chou as example at NXP link :

How do I run from BOARD_SDRAM on MIMXRT1020-EVK?

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.

ithinkchen926 · ‎10-01-2019

Dear Jeremy,

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: