AnsweredAssumed Answered

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

Question asked by David Rodgers on Oct 15, 2019
Latest reply on Oct 16, 2019 by David Rodgers

Hi Jay Heng,


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.