Debug application with shifted start address

[robgal519]

In my linker script I have shifted address to 0x08020000 ( on 0x08000000 is bootloader)

#if !defined(MBED_APP_START)
  #define MBED_APP_START 0x08020000
#endif

#if !defined(MBED_APP_SIZE)
  #define MBED_APP_SIZE 400K
#endif
...
MEMORY
{ 
  FLASH (rx) : ORIGIN = MBED_APP_START, LENGTH = MBED_APP_SIZE
  RAM (rwx)  : ORIGIN = 0x200001C8, LENGTH = 256K - (0x1C4+0x4)
}
...

I found out that this causes major issue. When I use project that starts from 0x08000000 everything runs OK, but in my case, The debuging starts, and debugger stops on first instruction( reset handler as expected) When I run any action, continue or step, I loose control of the debugging, the mocrocontroler does not run.

Below You can find output of the console: Please check OUTPUT tab (Adapter Output) for output from JLinkGDBServer Launching server: "JLinkGDBServer" "-if" "swd" "-port" "50000" "-swoport" "50001" "-telnetport" "50002" "-device" "stm32F412ZG" Launching GDB: "/usr/bin/arm-none-eabi-gdb" "-q" "--interpreter=mi2" Reading symbols from /*********************************************************************.elf... done. 0x08005268 in ?? () Not implemented stop reason (assuming exception): undefined Resetting target Resetting target

my config:

       {
            "cwd": "${workspaceRoot}",
            "executable": "${workspaceRoot}/src/BUILD/********.elf",
            "name": "Debug Microcontroller - jlink",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "jlink",
            "device": "stm32F412ZG",
            "svdFile": "${workspaceRoot}/../STM32F412.svd",
            "armToolchainPath": "/usr/bin",
            "preLaunchTask": "buildApplication",
            "interface": "swd"
        },

VScode version

Version: 1.41.1
Commit: 26076a4de974ead31f97692a0d32f90d735645c0
Date: 2019-12-18T15:04:31.999Z
Electron: 6.1.5
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Linux x64 4.15.0-74-generic

As I mentioned above, It seems that starting address of application can not be changed or the cortex debug will not work. I reproduced this issue with Jlink debugger, and OpenOCD, both with the same result, the debugging starts on reset handler, but, when I do anything, it runs off, and I can not do anything ( the microcontroler does not run the code)

[haneefdm]

This extension does not do anything special to your program execution other than look at the executable to see where the symbols are (addresses) if symbols exist. The exception you see at the beginning is how the device stops at the reset vector and how JLink/OpenOCD report the halt at the reset vector. Once a continue/step/next is issued after the reset vector, we simply wait until JLink/OpenOCD report back a halt due to whatever reason (breakpoint, fault, exception, etc.) or if you manually halt it.

Can you debug via command-line tools (gdb) for instance?

What you are seeing typically happens when the bootloader has a bug and ends up executing some bad ode.

[robgal519]

When I run arm-none-eabi-gdb in terminal, and attached to the port 50000 created by the vscode, I can see exactly the same bahaviour as in the editor.

When I manually run openocd, and then attach to the gdb server, it works fine.

This suggests, that some parameters of launching debug server are invalid.

I do not think that it has anything to do with bootloader, because when I debug the application there is no bootloader, I just put my code at address 0x08020000, and start execution from there.

I suspected the changed address to be an issue, because when I swapped the elf file to bootloader, which starts from 0x08000000, everything worked fine

[haneefdm]

For now, you can also use the attach method with CortexDebug. In launch.json use "request": "attach". I do this all the time for one of my applications because that device cannot be programmed via JLink/OpenOCD -- wireless programming only (an IOT device) and again a bootloader is involved.

Basically, if you cannot get gdb command-line to work, then neither can CortexDebug. I don't have enough knowledge about your application structure, so I can't tell you how to solve it.

[robgal519]

Thank you @haneefdm for the advice. I tested your solution and it seems to work fine :D

The crucial thing is that the flash starts at start of the sector, and reset is not called.

When the reset is called, it automatically starts from 0x08000000. If I got a boot loader there, it would possibly call correct reset handler and it would be fine, but i can not assume that.

Current config for others to use

        {
            "cwd": "${workspaceRoot}",
            "executable": "./build/echo.elf",
            "name": "Debug Microcontroller",
            "request": "attach",
            "type": "cortex-debug",
            "servertype": "bmp",
            "device": "STM32F407VE",
            "BMPGDBSerialPort": "COM9",
            "targetId": 1,
            "preAttachCommands": ["load", "break main", "continue"],
            "overrideRestartCommands": ["jump Reset_Handler"],     
        },

I'm sorry for the confusion, I use different debuggers, but the core issue was the same.

Because the issue was not connected with the Cortex-Debug but rather with the way microcontrollers work in general, the issue can be closed