MCUXpresso for VSCode中的主题 Debug application started by the MCUBOOT

Debug application started by the MCUBOOT

jslota13245 — Fri, 19 Jun 2026 11:24:22 GMT

Dear Everyone,

the board we use is IMXRT1176.

I would like to debug my application which is started by mcuboot. I would like the debugger to flash a signed application and debug it afterwards. Let me show you what i did:

1. Original build produced me an app.elf

2. I converted an app.elf to app.bin and singed it with imgtool to create app_signed.bin

3. I used arm-none-eabi-objcopy to wrap app_signed.bin into app_signed.bin.elf

4. I used this lanuch.json configuration

```

{
"type": "mcuxpresso-debug",
"name": "Debug bootloader app",
"request": "launch",
"cwd": "${workspaceFolder}",
"executable": "<PATH_TO_BIN>/app.elf",
"isAttach": false,
"probeType": "LinkServer",
"stopAtSymbol": "main",
"skipBuildBeforeDebug": true,

"extraSymbolFiles": [
"<PATH_TO_BIN>/app.elf",
"<PATH_TO_BOOTLADER>/bootloader.elf",
],

"postLaunchCommands": [
"load <PATH_TO_BIN>/app_signed.bin.elf 0x30100000"
],

"gdbInitCommands": [
"set remotetimeout 600",
"set debug-file-directory",
"set non-stop off",
],

"gdbServerConfigs": {
"linkserver": {
"device": "MIMXRT1176xxxxx:MIMXRT1170-EVKB",
"core": "cm7",
},
"segger": {},
"pemicro": {}
},
},
```

It seems to work, meaning i can debug both bootloader and app, but it feels like a hack.

What I don't like the most is that flash is written twice. Once for executable where we write unsigned binary and one for load where we write signed binary (which has the same core code obviously).

Could you please tell me if i missed something obvious? Do you think there is a cleaner way to achieve that.

Just as an info, I know how to attach to already flashed image, the process above is more about convenience to start debugging in one step, I mention this to express what my goal is.

Thanks a lot in advance for any help and suggestions!

Best Regards,
Jakub

Re: Debug application started by the MCUBOOT

Habib_MS — Mon, 22 Jun 2026 22:47:28 GMT

Hello @jslota13245,

There are currently no defined steps that combine flashing and debugging a signed image into a single workflow, as these are typically handled as separate processes. In general, you would first flash the signed image onto the device and then attach the debugger afterwards. As a reference, you may find it helpful to review the "Running the demo" section of the ota_mcuboot_basic example, which demonstrates two different approaches for flashing a signed image that could be adapted to your setup. Additionally, the "Transferring data" to the flash memory section provides an overview of the available tools that can be used for the flashing process.

On the other hand, could you please clarify the reason for converting the signed image into a .bin.elf file? Also, could you confirm if you followed a guide for this process?

BR
Habib

Re: Debug application started by the MCUBOOT

jslota13245 — Tue, 23 Jun 2026 07:10:29 GMT

Hello Habib!

thank you for the reply.

To answer your question. I followed this guide for flashing multiple binaries at the start-up. We use mcuxpresso for vs-code instead of IDE but the premise should be the same:

https://mcuoneclipse.com/2022/11/01/loading-multiple-binary-files-with-gdb/

The idea here is that the elf file has information to debug a signed binary, as signed binary is just a binary with header and trailer attached. If the .elf file was generated with this layout in mind it should work as intended.

For future reference, approach i suggested in my original post doesn't work too well as debugger gets stuck on non-existing 0x00000 breakpoints while the CPU is still running so i suspect no real crash has occurred. There is clearly some configuration/integration debugger problem here but I can't point exactly where. Did you encounter such behaviour by any chance?

As for your suggested approach, I found this section:
```

programing signed application image to the primary application partition using an external tool (direct method)
jump-starting the application by debugger, performing an image update with the signed image, resetting the board and letting the bootloader to perform the update (indirect method)

The latter method is used in the following step-by-step description:

Open the demo project and build it. Known issue: MDK linker issues warning about unused boot_hdr sections. This does not affect the functionality of the example.
Prepare signed image of the application from raw binary as described in the readme of mcuboot_opensource SDK example.
- In case of MCUXpresso raw binary may not be generated automatically. Use binary tools after right clicking Binaries/.axf file in the project tree to generate it manually.
Launch the debugger in your IDE to jump-start the application.
- In case of MCUXpresso IDE the execution stalls in an endless loop in the bootloader. Pause the debugging and use debugger console and issue command jump ResetISR.
  
```

But I'm a bit lost on what do i need to do with the extension for VS-code - I don't have ide backend unfortunately. Could you please help me by answering the questions below?

Let's assume i do have a signed binary and original elf file with symbols.

1. How can debugger kick start signed image?
2. How can debugger kick start it without flashing it first? The point 1 explicitly states to flash it with some tool - i assume point 2 does something else?.

3. The debugger can't flash just base elf file as it'll be discarded by the mcuboot as it doesn't have mcuboot header and a trailer.

4. When point 2.3 states 'Launch the debugger in your IDE to jump-start the application' - does it mean the debugger flashes something? Or does it attach to already flashed image?

Thanks in advance for your help and time

Best Regards,
Jakub