- This topic has 8 replies, 2 voices, and was last updated 4 years, 1 month ago by
.
-
Posts
-
Hi!
<table style=”border-collapse: collapse; width: 54.6205%;” border=”1″>
<tbody>
<tr>
<td style=”width: 10.511%; text-align: right;”>Board:</td>
<td style=”width: 44.157%;”>DISCO_L072_LRWAN1</td>
</tr>
<tr>
<td style=”width: 10.511%; text-align: right;”>VisualGDB:</td>
<td style=”width: 44.157%;”>v5.5.3826</td>
</tr>
<tr>
<td style=”width: 10.511%; text-align: right;”>Toolchain:</td>
<td style=”width: 44.157%;”>MDK-ARM v5.32</td>
</tr>
<tr>
<td style=”width: 10.511%; text-align: right;”>Debug Tool:</td>
<td style=”width: 44.157%;”>Segger J-Link</td>
</tr>
</tbody>
</table>
Trying to debug Mbed-OS application with VisualGDB via Segger_J-Link+J-Link_Software+SWD but only assembler code debugging is available, no source code debugging. When debugging starts the message “Frame not in Module” appears with proposition to continue with assembler code.Meanwhile when using standalone “Ozone” J-Link debugging tool the ELF-file is loaded to board and source debugging is performed just fine.
Could anybody give a clue what to tune up to make VisualGDB do source debugging?
Thanks!
—
Regards, PavelHi,
Please make sure your build the project before debugging. If it doesn’t help, please attach the gdb session log here and we will check what is going on.
It looks like you are setting breakpoints in one project and are trying to debug another one. Based on the gdb log, the breakpoint is set in the following file:
C:/Users/dlp/source/repos/MbedProject_testCDC/mbed-os/targets/TARGET_STM/TARGET_STM32L0/TARGET_STM32L072xZ/TARGET_DISCO_L072CZ_LRWAN1/system_clock.c
The -file-list-exec-source-files command reports a different file:
C:/Users/dlp/source/repos/MbedProject_LoRa/mbed-os/targets/TARGET_STM/TARGET_STM32L0/TARGET_STM32L072xZ/TARGET_DISCO_L072CZ_LRWAN1/system_clock.c
Please double-check your settings and make sure you debug the correct project.
Dear Support,
The reason you’ve pointed out doesn’t seem to be the real one. I’ve removed all the breakpoints and set just the single one in the main function. No breakpoints from other project but nothing changed, the error is the same. I added the log for you to analyse once more.
Thanks for you concern!
—
PavelNo problem. It looks like the gdb debugger is not able to properly report the source location of the breakpoint event:
*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x08013366",func="main",args=[],arch="armv3m"},thread-id="1",stopped-threads="all"This sometimes happens due to a bug in the Keil compiler that produces invalid DWARF debug symbols and typically affects code in a specific file beyond a certain line. As a workaround, please consider using the GCC compiler, or try splitting the source file into multiple smaller files. You can also experiment with setting breakpoints in different files to see if there is any pattern.
Maybe it’s a kind of bug in ARM(Keil) compiler but the debug info produced by it is completely normal for “Ozone” J-Link debugger and there’s no problen with source code line numbers and symbols. Using GCC is very problematic because it produces much bigger code and has problems with some Mbed-OS runtime code parts. So I NEED to setup VisualGDB to work correctly when debugging code produced by ARM(Keil) compiler toolchain. I think you are also interested in illustration that VisualGDB is compatible with ARM compiler toolchain and Mbed-OS. I only need to know what additional informaition you require to solve the problem jointly.
Thanks a lot for your help.
Sorry, VisualGDB uses the gdb debugger to debug the code, while Ozone uses its own debugging engine. If the specific project produces an image that breaks gdb, it is outside of VisualGDB’s control to fix this, as it relies on gdb internally. The only workaround we can suggest would be to try a different Keil/GDB version.
- You must be logged in to reply to this topic.