No source code debugging in Visual Studio 2019

Sysprogs forums Forums VisualGDB No source code debugging in Visual Studio 2019

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #29216
    pavel_dlp
    Participant

    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, Pavel

    Attachments:
    You must be logged in to view attached files.
    #29221
    support
    Keymaster

    Hi,

    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.

    #29223
    pavel_dlp
    Participant

    Thank you for replay! I checked build – all is ok. I will attached log file. Help me, please…

    Attachments:
    You must be logged in to view attached files.
    #29225
    support
    Keymaster

    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.

    #29226
    pavel_dlp
    Participant

    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!


    Pavel

    Attachments:
    You must be logged in to view attached files.
    #29230
    support
    Keymaster

    No 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.

    #29231
    pavel_dlp
    Participant

    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.

    #29234
    support
    Keymaster

    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.

    #29235
    pavel_dlp
    Participant

    Thx for your help! When i work with cpu with large memory – gcc is wery nice and debug work good. Thx for good Visual DBG! Work debug with small memory by different dbg is not a problem now.

    Thx for replay!

    Best regards, Pavel

Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.