Bootloader code execution slow

[sandeepc]

Hi, we are developing custom bootloader for our application we are facing issue jumped application running.

So we are using External SDRAM for our project, so we configured SDRAM in boot project as well as Application project.

FAST working Scenario:

For example Our application Code Runs default nxp specified address at 0x30000000 it is working faster with expected results.

Slow scenario:

When i create the bootable image just by changing 0x30000000  to 0x30025000. application jumping successfully, but all the configured peripherals working slower, 

Try1:

We tried by keeping the boot project and application project with same configuration, but application still running slow.

example; if i send CAN message with 10ms from host to ECU , but ECU is taking time to to respond >15ms.

So how can i resolve this issue? is it any particular configuration needs to be done in boot application or while creating custom address bootable image.

@kerryzhou @kef2 

Regards,

Sandeep C

[diego_charles · Accepted solution]

Hi @sandeepc 

Thank you for your patience.

Which i.MX RT MCU are you using? Typically, the SDRAM executes at 0x8000_0000 on RTxxxx. The RT11xx flash area is located at 0x3000_0000 space. Could you clarify this too?

Is the image at 0x30025000 booted by your custom bootloader or the ROM bootloader? As a general advice, I recommend adding specific clock settings for your application image, not completely relying on the setup left by bootloader that boot the executing image. For example, MCUXpresso Config tools lets create custom clock settings for your image. If the execution code runs slow, you might want to create custom clock setting for the core clock in your application image.

If you have more details to share, please let me know.
Diego

[sandeepc]

Thanks for the reply,
It was a flexspi clock issue.
Problem was in boot code. flex spi we are configuring clock divider 2 , in application we are not configured to increase the flexspi clock,
so we changed flexspi clock divider to 1.
it works fine.