How to handle debug when we have 2 application banks like in the AWS reference bootloader

[sumanclimote]

I have been trying to use this with the AWS IOT SDK but the debug was not working as expected. When I went deep in I realized that there are 2 application bank and bootloader chooses the bank. More details of this is shared in the below link - https://docs.aws.amazon.com/freertos/latest/userguide/images/application-image-structure.png https://docs.aws.amazon.com/freertos/latest/userguide/microchip-bootloader.html

When I flash the application is only flashed in 1 bank and bootloader is choosing another so I am not able to debug the code, can you please help me to modify so that we flash both banks so that the debugging can be correct always. Or please suggest me how to handle this case.

[haneefdm]

Good question! If you were using Eclipse or some other tool, how is this handled?

[haneefdm]

Oh wait. This should already work. When you compile and link, the linker script is loaded to specific addresses. So, "image0" has one set of addreses and executable and "image1" has another set of addresses and executable (elf file).

You have to either image0.elf or image1.elf knowing which image the bootloader is going to use. If you are debugging one of those images, it would be a mistake to tell us/gdb that you are debugging the bootloader (which is a separate image/executable).

So, you have 3 images and you should decide which image/executable you are debugging.

A similar thing also applies where the image is loaded into RAM from external/internal FLASH

[sumanclimote]

Hi, I am using VS code and ST-link . get only 1 elf file from the compiler for application and the bootloader is not built or flashed during development time (in my case).

[haneefdm]

So, how do you debug if you were using STM32CubeIDE? Do you have screenshots? Commands it runs, etc.?

Also, how is your application program flashed then? Do you use some other mechanism?. Currently, you are using what is called "request": "launch". You can also use "request": "attach". When you use this, the debugger attaches to a running program. No program will be flashed. You can reset after if you want.

Can you attach a copy of your launch.json?

[sumanclimote]

launch.json file as requested -

{ // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ {

        "cwd": "${workspaceRoot}" ,
        "executable": "<full path>/build/aws_demos.elf",
        "name": "Debug code",
        "request": "launch",
        "type": "cortex-debug",
        "runToEntryPoint": "main",
        "showDevDebugOutput": true, //"none",            
        "servertype": "stlink",
        "gdbpath": "/usr/bin/gdb-multiarch",
        "svdFile": ".....<full path>/STM32L4x1.svd",
        "device": "STM32L4",            
    }

]        

}

[lidavid]

You can tell the GDB server to load more symbol files. Here is an example of my launch configuration:

       {
            "name": "bootable application",
            "cwd": "${workspaceRoot}",
            "executable": "build/bootloader/bootloader.elf",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            "configFiles": [
                "openocd/scripts/interface/ftdi/olimex-arm-usb-ocd-h.cfg",
                "openocd/scripts/interface/ftdi/olimex-arm-jtag-swd.cfg",
                "openocd/scripts/target/max32650.cfg"
            ],
            "armToolchainPath": "C:\\Maxim\\Toolchain\\bin\\",
            "serverpath": "C:\\Maxim\\Toolchain\\bin\\openocd.exe",
            "svdFile": "${workspaceRoot}\\main\\CMSIS\\Device\\Maxim\\MAX32650\\Include\\max32650.svd",
            "postLaunchCommands": [
                // enable debug of bootloader.elf, configfile.elf, spl.elf and application.elf togther
                "add-symbol-file build/configfile/bootable/configfile.elf 0x10004000",
                "add-symbol-file build/spl/image/spl.elf 0x10008000",
                "add-symbol-file build/app/bootable/app.elf 0x10048000"
            ],
            "breakAfterReset": true
        },

[haneefdm]

Thanks @lidavid One problem is that the Globals and Statis will not be populated because of the following

           "executable": "build/bootloader/bootloader.elf",

This should really be the executable you are actually debugging. The rest can be in the postLaunchCommands. You can also take control of which file gdb uses to download using either loadFiles or overrideXXXX settings.

It also affects disassembly. Perhaps the list of symbol files should actually be a list provided to Cortex-Debug. We do not parse what is postLaunchCommands

[haneefdm]

In 1.5.x (1.5.1 is the latest pre-release on Marketplace as of now), there is also the ability to load symbol files via the symbolFiles setting. This way, gdb and us, both have the same worldview of the symbols.