iMXRT1170 boot from OCRAM

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

iMXRT1170 boot from OCRAM

Jump to solution
4,532 Views
muhammadumairkh
Contributor III

Hello NXP,

I am using the STKa117xL board from TQ. The board has an iMXRT1170 microcontroller on it and I want it to boot from OCRAM. The use case is that the code will be downloaded to Flash memory and upon POR, the ROM bootloader copies the relevant code from flash memory to OCRAM. The code will then start execution from OCRAM.

I went through the steps mentioned on https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/I-MX-RT-How-to-booting-to-SDRAM/ta-p/1125054 but they bore no fruit. Can you provide detailed documentation to achieve this? Any fuse bits that I need to configure?

Thanks,
Umair

0 Kudos
Reply
1 Solution
4,058 Views
Omar_Anguiano
NXP TechSupport
NXP TechSupport

Yes, this is expected behavior.  Some portion of OCRAM1 is used during startup so it also needs to be considered on the offset.

Omar_Anguiano_0-1675222383183.png

Best regards,
Omar

View solution in original post

0 Kudos
Reply
19 Replies
4,460 Views
muhammadumairkh
Contributor III

Hi @Omar_Anguiano ,

Thanks for your response. I tried that using the MCU Xpresso SDK and the MCU boot utility and it worked like a charm. Thanks for being helpful.

Now I have another question. I am using another IDE with GNU GCC toolchain to build bare-metal images (I am not using the NXP SDK). I have been able to successfully execute them via JTAG and they are also executing fine in-place (XIP) from flash also. So execution wise there is no problem, I am all set. But when I use that image (I stripped off the IVT and other headers because I know I don't need them for OCRAM boot) in the MCU boot utility, the output image doesn't boot. When I compare it with that generated using the MCU Xpresso SDK + MCU Boot, the boot header at 0x1000 is not correct (missing the entry point address at 0x1004 offset and some other differences also). May be, the MCU Xpresso generates some symbols in the .axf file that the MCU boot can parse and generate the bootable image accordingly. And since my GCC out file does not have those symbols, it does not work. Can you help me identify what I am missing here?

Thanks.

0 Kudos
Reply
4,415 Views
Omar_Anguiano
NXP TechSupport
NXP TechSupport

IVT is needed even if you´re using OCRAM. The image will be in flash but at boot time it will be copied to OCRAM so it executes from there.
Please refer to this post: Generating a Bootable Image for the RT1050 - NXP Community

Best regards,
Omar

0 Kudos
Reply
4,403 Views
muhammadumairkh
Contributor III

Thank you @Omar_Anguiano for your response. Let me ask my question differently...

  1. I compiled a blinky application using MCU Xpresso IDE. I supplied the output *.axf file to the MCU boot utility and generated the output bootable image. I then flashed the image to the target board and it booted successfully from OCRAM. 

  2. Next, I used the same procedure but instead of supplying the .axf file, I supplied the .bin file in the MCU boot utility. I compared the generated output file with the one generated in case 1 and found that there are some differences as shown in the below figure:

muhammadumairkh_0-1671021642961.png

The question is that what is wrong in my procedure that the output is not the same as that of the axf file? Please help me with this. Thanks.

Thanks and Best Regard,
Umair Khan

 

0 Kudos
Reply
4,386 Views
Omar_Anguiano
NXP TechSupport
NXP TechSupport

Could you please describe the process to generate the bin file? MCUXpresso creates a binary with this command from an axf file:

Omar_Anguiano_0-1671490844525.png

It is expected for bin and axf to be different since axf also contains debug information.

So, both axf and bin file you loaded to MCUBoot are from the same image with the same parameters? I will be helpful if you detail to me how are you generating the bin file.

Best regards,
Omar

0 Kudos
Reply
4,379 Views
muhammadumairkh
Contributor III

Hello @Omar_Anguiano . Thanks for the response.

I generated by bin file by right clicking the axf > Binary Utilities > Create binary as below:

muhammadumairkh_0-1671523128044.png

And yes, both the axf and bin belong to the same project.

-Umair

 

0 Kudos
Reply
4,364 Views
Omar_Anguiano
NXP TechSupport
NXP TechSupport

Thank you for the information.

Could you please attach a screenshot of the values written in the following path of MCUXpresso:
Windows->Preferences->Utilities.
Additionally, which IDE version are you using?

Best regards,
Omar

0 Kudos
Reply
4,360 Views
muhammadumairkh
Contributor III

Hi @Omar_Anguiano . Thanks for the response.

Below are the screenshots for both:

muhammadumairkh_0-1671780511477.png

and 

muhammadumairkh_1-1671781287648.png

Thanks and BR,
Umair Khan

0 Kudos
Reply
4,293 Views
Omar_Anguiano
NXP TechSupport
NXP TechSupport

Thank you for the additional information.
I suggest you use the last IDE version to check if this issue still persists.
Additionally, when using the bin file on MCUBootUtility does an error display? Or the tool can write the image but does not run correctly during execution.

Best regards,
Omar

 

0 Kudos
Reply
4,289 Views
muhammadumairkh
Contributor III

Thank you @Omar_Anguiano . No, the MCU boot does not throw any error when .bin file is used. It is as smooth as it is with the axf file. Here is the output log of the MCU boot:

'Generate Bootable Image' button is clicked
Bootable image is generated: C:\MCU_Boot_Utility\NXP-MCUBootUtility-master\gen\bootable_image\ivt_evkmimxrt1170_iled_blinky_cm7_unsigned.bin

Also, I am using version 3.5.0 of the MCU boot utility.

Umair

0 Kudos
Reply
4,254 Views
Omar_Anguiano
NXP TechSupport
NXP TechSupport

Thank you!
It will be helpful to check if this is persistent with the latest MCUXpresso version or using secure provisioning tool that works similarly to MCUBootUtility.

Best regards,
Omar

0 Kudos
Reply
4,228 Views
muhammadumairkh
Contributor III
Hi Omar. I will try it out and respond back.
0 Kudos
Reply
4,165 Views
muhammadumairkh
Contributor III

Hello @Omar_Anguiano .

I tried the secure provisioning tool and it works. The base address I was using in the MCU Boot utility was incorrect which was causing the problem. I first used the .axf file in the secure provisioning tool and it auto-populated the base address. There I realized that the base address setting was incorrect for MCU Boot utility. Now it works fine for the bin file as well.

I have another observation and a question. You suggested in your earlier comment to set the OCRAM_BASE to BASE + 0x3000 but I see that it does not boot until the offset is greater than or equal to 0x10000 (0x2025000). I tried below values but none worked:

  1. BASE + 0x3000 = 0x20243000
  2. BASE + 0x4000 = 0x20244000
  3. BASE + 0x4000 = 0x20244000
  4. BASE + 0x5000 = 0x20245000
  5. BASE + 0x6000 = 0x20246000
  6. BASE + 0x7000 = 0x20247000
  7. BASE + 0x8000 = 0x20248000
  8. BASE + 0x9000 = 0x20249000

However, below combinations work:

  1. BASE + 0x10000 = 0x20250000
  2. BASE + 0x11000 = 0x20251000
  3. BASE + 0x12000 = 0x20252000

My question is that is it the expected behaviour?

Thanks.

0 Kudos
Reply
4,059 Views
Omar_Anguiano
NXP TechSupport
NXP TechSupport

Yes, this is expected behavior.  Some portion of OCRAM1 is used during startup so it also needs to be considered on the offset.

Omar_Anguiano_0-1675222383183.png

Best regards,
Omar

0 Kudos
Reply
4,048 Views
muhammadumairkh
Contributor III

Thanks @Omar_Anguiano . So it looks like we need to add a 0x3000 offset after the reserved RAM space. From the figure you attached, the correct address comes out to be 0x2024BFFFF + 0x3000 = 0x2024FFFF which is what I observed.

Anyway, thanks for the continued support. This answers my question.

0 Kudos
Reply
4,483 Views
Omar_Anguiano
NXP TechSupport
NXP TechSupport

The steps are the same as using an internal RAM

1. Select Project > Properties - C/C++ Build > Settings > Tool Settings > MCULinker > Managed Linker Script and check Link application to RAM.
2. In Project > Properties > C/C++ Build > MCU settings, delete Flash, and modify SRAM_OCRAM to start at (BASE + 0x3000) with size (SIZE - 0x3000).
3. Move SRAM_OCRAM to the first position to make it default.
4. Build the image.

Then you can use MCUBootUtility to load that image.

Best regards,
Omar

0 Kudos
Reply
3,971 Views
Oliver_R
Contributor I

Hi Omar,

I'm very sorry but it's still not clear what to do. I'm using the same baseboard as the thread starter and I'd like to start my program from SRAM, too (because network speed is much faster).

Do you mean with "modify SRAM_OCRAM to start at (BASE + 0x3000)" that I should change the Location of SRAM_OC1 to 0x20243000 and the size to 0x7d000 (for the RT1176)? It's very hard to follow if you're using different terms for the things I should change in the IDE.

OK, link to RAM checked, I build my image. But what follows after that? Flashing the .axf file with the Secure Provisioning Tool leads to a non-booting program. I can't change the start address in this case.

If I create a bin file from the .axf in the IDE then it is possible to change the start address in the provisioning tool but it doesn't allow a start address of 0x2024ffff:

"ERROR: Incorrect address value or invalid image content. Invalid image start address. Based on the detected application entry point address 0x202434CD and image size 418484, the start address shall be in range 0x201DD219-0x202434CD."

So, do I use the MCUBootUtility for this purpose? Or is it possible to use the secure provisioning tool, too? What settings do I have to use?

Unfortunately the MCUBootUtility does not work on my computer (it does not find the correct USB-IDs) although the secure provisiong tool works without a problem.

The information about this subject is very hard to find as it is spread over various MCUs or maybe includes outdated information.

Please give me some hints!

Bye,

Oliver

0 Kudos
Reply
4,488 Views
muhammadumairkh
Contributor III

Hi @jay_heng . Thank you for your response. 

We have tried the MCU Boot Utility but our board is not booting from OCRAM. Do you have a demo application and documented set of steps for OCRAM boot?

Thanks.

0 Kudos
Reply
4,456 Views
jay_heng
NXP Employee
NXP Employee

You need to build a Non-XIP image first. and also make sure reserve first 8KB for BootROM

- For ITCM, you need to link image from 0x2000 instead of 0x0.

0 Kudos
Reply
4,504 Views
jay_heng
NXP Employee
NXP Employee

You can try MCUBootUtility tool to do this. it is very easy

0 Kudos
Reply