Ask questionsCannot start debug, when flash address is not set to default value in linker script
my application is splitted in several memory areas via linker script file.
The main application is starting not at address 0x08000000, but at 0x08010200.
The Program counter address is: 0x08010200.
The stack pointer address is: 0x0C010200.
When I try to start to debug I got the following failure:
Please check OUTPUT tab (Adapter Output) for output from C:/Program Files (x86)/SEGGER/JLink/JLinkGDBServerCL.exe Launching server: "C:/Program Files (x86)/SEGGER/JLink/JLinkGDBServerCL.exe" "-if" "swd" "-port" "50000" "-swoport" "50001" "-telnetport" "50002" "-device" "XMC4500-F144x1024" Launching GDB: "C:\GnuToolChain\9_2019_q4_major\bin\arm-none-eabi-gdb.exe" "-q" "--interpreter=mi2" undefinedC:\GnuToolChain\9_2019_q4_major\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory. Reading symbols from <path>/application.elf... 0x000000e2 in ?? () Not implemented stop reason (assuming exception): undefined Resetting target Resetting target SWO enabled successfully. Warning: the current language does not match this frame. Exception condition detected on fd 552
When I try to debug the same *.elf file in Segger Ozone, debugging works without a problem. My expectation is, that the debugger automatically knows where to flash and where to start the application, like Ozone is doing this. I can reproduce this behavior, by just changing the location. Do I need to set a parameter to be able to debug in VSC or ist this a failure?
Answer questions haneefdm
What I don't see in the gdb output is loading the target. I see the following sequence
target remote localhost:50000 monitor reset
And, then, it looks like it is attaching to a running program and gdb is asking you for a file to load for symbols as, without it, it won't work. In JLink output, do you see the programming happen?
I will give you two options below. The first one bypasses programming
"overrideLaunchCommands" : [ "monitor halt", "monitor reset", "-target-download", "monitor reset", "enable-pretty-printing" ]
This is what Cortex-Debug does to start the debugging session. You can change this sequence or comment out the download and the following reset
I believe. in Ozone, you can use an elf file to debug but a bin/hex file to program. If so, you can do the same. target-download makes gdb send the programming regions to link, but if you have a bin/hex file, you can replace target-download with
"preLaunchCommands": [ "exec-file path-name-to-hex-or-elf-file" ]
Oh, you should enable debug output to see exactly what is going on