VisualGDB Debugging Features not Working

Sysprogs forums Forums VisualGDB VisualGDB Debugging Features not Working

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #31391
    smadeux
    Participant

    I’m currently testing out the VisualGDB Debugging features and I’ve run into a few problems that I was hoping to get some help with.

    I’ve found that under VisualGDB Project Properties>Debug Settings, I need to have the Program FLASH memory setting set to Always otherwise it won’t hit any of my breakpoints and when I pause the program, I get a screen with the message “Frame is not in the module” (Translated from German “Rahmen ist nicht im Modul”).

    The same thing happens when I’m debugging, and I try to use the Reset Embedded Device button. None of the breakpoints are hit, the program appears to not be actually running and I get the same screen as above.

    Are there any known reasons why the “Program FLASH memory: If rebuilt since last load” option would not be working properly as well as the Reset Embedded Device button?

    I’m using an STM32F437VI board connected to my PC with an STLink-V3 Debugger/Programmer. Please let me know what other information would be useful.

    #31392
    support
    Keymaster

    Hi,

    No problem. You can review what is going on by enabling the gdb logging as shown here. Normally, if you do not program the device each time, VisualGDB will simply reset it using the “mon reset init” command.

    Please try checking the gdb log file and make sure it contains the reset command. If not, please ensure one of the reset checkboxes is set in VisualGDB Project Properties -> Debug Settings.

    If the reset command is present in the log file, please try running it manually and checking if it manages to reset the device correctly.

    #31405
    smadeux
    Participant

    I took a look at the log file and the reset command is definately present. Here is a snippet of the log file from when I hit the Reset Embedded Device button:

    [ 55499 ms] ~"Reading in symbols for C:/projects/HMI17/Source/RTOS/Core/Micrium/ucCPU/Port\\cpu_a.s...\n"
    [ 55500 ms] ~"\nProgram"
    [ 55500 ms] ~" received signal SIGINT, Interrupt.\n"
    [ 55512 ms] ~"CPU_SR_Restore () at C:/projects/HMI17/Source/RTOS/Core/Micrium/ucCPU/Port\\cpu_a.s:113\n"
    [ 55512 ms] ~"113\t MSR PRIMASK, R0\n"
    [ 55512 ms] *stopped,reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",frame={addr="0x08060200",func="CPU_SR_Restore",args=[],file="C:/projects/HMI17/Source/RTOS/Core/Micrium/ucCPU/Port\\cpu_a.s",fullname="C:\\projects\\HMI17\\Source\\RTOS\\Core\\Micrium\\ucCPU\\Port\\cpu_a.s",line="113",arch="armv7e-m"},thread-id="1",stopped-threads="all"
    [ 55512 ms] mon reset init
    [ 55513 ms] ~"Current language: auto\n"
    [ 55513 ms] ~"The current source language is \"auto; currently asm\".\n"
    [ 55533 ms] &"mon reset init\n"
    [ 55535 ms] @"Unable to match requested speed 2000 kHz, using 1000 kHz\n"
    [ 55536 ms] @"Unable to match requested speed 2000 kHz, using 1000 kHz\n"
    [ 55566 ms] @"target halted due to debug-request, current mode: Thread \n"
    [ 55566 ms] @"xPSR: 0x01000000 pc: 0x08001ca0 msp: 0x10000200\n"
    [ 55583 ms] ^done
    [ 55583 ms] x/4xb 0x8060200
    [ 55583 ms] &"x/4xb 0x8060200\n"
    [ 55595 ms] ~"0x8060200 :\t0x80\t0xf3\t0x10\t0x88\n"
    [ 55595 ms] ^done
    [ 55595 ms] -exec-continue
    [ 55609 ms] ^running
    [ 55609 ms] *running,thread-id="all"

    I also tried running the “mon reset init” command manually and the same thing as before happened. I’ve attached a screenshot below as well as a screenshot of my Debug Settings.

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

    Hi,

    This means that VisualGDB is working as expected – it is resetting the device. It is hard to say why a particular program would not be working after a soft reset. You can try ensuring that the reset works for a basic “Blinking LED” program, and then comparing it side-by-side with your one, until you find what is causing the difference. If you prefer, we can also gladly do it for you via a screen sharing session billed at our consulting rate. Feel free to contact our sales if you would like to get more details.

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