NXP-MCUBootUtility 2.0.0 - Target non-functional, differences in header data?

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

NXP-MCUBootUtility 2.0.0 - Target non-functional, differences in header data?

Jump to solution
1,808 Views
dmarks_ls
Senior Contributor I

Hi jayheng‌,

Unfortunately I've run into another issue with the MCU Boot Utility.  If I flash my application into my board using JTAG (via SEGGER pod), everything is fine.  But if I use the MCU Boot Utility, it looks like it alters some of the header information in my image, and the target no longer boots after setting BOOT_MODE back to Internal Boot.  Reflashing the unit again through the SEGGER pod works fine.

I've attached the files I'm working with.

  • my_project.srec - the SRecord file which I feed to the "Application Image File" input in the green box.
  • my_project_extracted.srec - the SRecord file which the utility generates when clicking "Generate Unsigned Bootable Image".
  • first_64k_works.bin - the extracted first 64KB of QSPI flash when the target has most recently been flashed by the SEGGER pod through the MCUX debugger.
  • first_64k_broken.bin - the extracted first 64KB of QSPI flash when the target has most recently been flashed by the MCU Boot Utility using my_project.srec
  • evkbimxrt1050_flexspi_nor_config.c - the C file for my QSPI flash DCD configuration data.
  • evkbimxrt1050_sdram_ini_dcd.c - the C file for my SDRAM DCD configuration data.

I've done a full 1MB extract and compare of the flash before and after the MCU Boot Utility touches the board, and the only difference is in the first few KB; the application code is intact.  When the debugger reflashes the target, it does so fairly quickly, hinting it's only erasing and rewriting the first page or two.

Why is the utility altering my header information, to the point where it doesn't work anymore?  Are you able to tell exactly what it's changing?  Is there any additional information you need?  I've been able to reflash our custom board through USB successfully in the past, so I'm not sure what's broken now.  Thanks.

David R.

0 Kudos
1 Solution
1,614 Views
jay_heng
NXP Employee
NXP Employee

Hi David,

  There are two ways to flash application image by MCUBootUtility.

  #1 Set image file (srec/hex/bin/axf/elf) path in "Application Image File" input box and click "All-In-One Action" button

pastedImage_1.png

   #2 Set image file (only bin file) path in "Bin File" input box and click "Write (Auto Erase)" button

pastedImage_3.png

  There are below differences between these two ways:

1).  #2 can only flash bootable image (with FDCB, IVT, BootData header), and the format must be binary (.bin). #1 can flash both raw image (only app, no header) and bootable image, and the format is unlimited.

2).  If provided image file is bootable image, #2 just flash this bootable image without any changes. #1 will only keep app and DCD, for FDCB, IVT, BootData, Tool will try to re-generate them according to settings in 'Boot Device Configuration' and image self

  so for your case, you can use #2 to flash image or set 'Boot Device Configuration' properly before using #1

Best Regards,

Jay

View solution in original post

3 Replies
1,614 Views
dmarks_ls
Senior Contributor I

Thanks, Method 2 is what I'm after.  I followed your steps (I left Start/Offset at 0x0, it was fine), gave it my BIN file, and it programmed fine.  Changed the boot jumper, power-cycled the target, and it worked fine.  Thanks for your help.

David Rodgers

0 Kudos
1,614 Views
jay_heng
NXP Employee
NXP Employee

If you decide to use #2, You need to set 'Run Mode' to Master in Tool menu

pastedImage_1.png

1,615 Views
jay_heng
NXP Employee
NXP Employee

Hi David,

  There are two ways to flash application image by MCUBootUtility.

  #1 Set image file (srec/hex/bin/axf/elf) path in "Application Image File" input box and click "All-In-One Action" button

pastedImage_1.png

   #2 Set image file (only bin file) path in "Bin File" input box and click "Write (Auto Erase)" button

pastedImage_3.png

  There are below differences between these two ways:

1).  #2 can only flash bootable image (with FDCB, IVT, BootData header), and the format must be binary (.bin). #1 can flash both raw image (only app, no header) and bootable image, and the format is unlimited.

2).  If provided image file is bootable image, #2 just flash this bootable image without any changes. #1 will only keep app and DCD, for FDCB, IVT, BootData, Tool will try to re-generate them according to settings in 'Boot Device Configuration' and image self

  so for your case, you can use #2 to flash image or set 'Boot Device Configuration' properly before using #1

Best Regards,

Jay