Debug application started by the MCUBOOT 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": " /app.elf", "isAttach": false, "probeType": "LinkServer", "stopAtSymbol": "main", "skipBuildBeforeDebug": true, "extraSymbolFiles": [ " /app.elf", " /bootloader.elf", ], "postLaunchCommands": [ "load /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 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 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 Re: Debug application started by the MCUBOOT Hello @jslota13245,
When you mention "I don't have ide backend unfortunately" I understand this may refer to limited familiarity with the MCUXpresso extension for VS Code, is my understanding correct? If so, I recommend reviewing the chapter "Explore Extension" in the official documentation for the extension, as it provides a helpful overview of its features.
Regarding your questions, when you start a debug session, the tool by default programs the generated image into flash and then attaches the debugger, which automatically jump to the main function. this is described in the "starting a debug sesion" section, inside this page you will find more information about the functionality of the debug in the extension. I can also, suggest you review the chapter "debug a project" which shows the steps to debug your code.
I highly recommend first validating and debugging your application without MCUboot or image signing and only introducing MCUboot once your application is fully tested. For make this process we strongly recommend using MCUxpresso Secure Provisioning Tool, which has the capabilities to manage security features such as key generation and image signing for MCUboot, which is why this is standard tool to handle applications just like this one. You can find more information about how sign image and flash your MCUboot in the chapter 7.6.2 " Steps to start MCUboot with such a processor manually"of the Secure Provisioning Tool User Guide 26.03.
On the other hand, when integrating MCUboot, ensure that it is placed in a dedicated flash region that is not overwritten by other images, the mcuboot_opensource_cm7 example offers an alternative of how place each image:
| Region | From | To | Size |
|----------------|------------|------------|--------|
| MCUboot code | 0x30000000 | 0x3003FFFF | 256kB |
| Primary slot | 0x30040000 | 0x3023FFFF | 2048kB |
| Secondary slot | 0x30240000 | 0x3043FFFF | 2048kB |
You should first program the MCUboot image into its dedicated flash region, and then place the signed application image into the primary or secondary slot. The MCUXpresso Secure Provisioning Tool can facilitate this process by handling both, program the bootloader and program the image within a single workflow, as described in section 7.6.2 of the user guide I previously shared.
BR Habib
查看全文
