FastSemihosting issue?

Sysprogs forums Forums VisualGDB FastSemihosting issue?

This topic contains 5 replies, has 2 voices, and was last updated by  Yuriy 3 weeks, 5 days ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #20724

    Yuriy
    Participant

    Hi!

    Sometimes VisualGDB crashes during debugging process. VisualStudio continues working after error message, or completely hangs.

    It happens not very often, and I can’t understand causes of this problem.

    VisualGDB log:

    Where can I find more VisualGDB logs to help locate problem?

    Attachments:
    You must be logged in to view attached files.
    #20745

    support
    Keymaster

    Hi,

    The InitializeFastSemihosting() function is normally invoked at the start of your debug session so that VisualGDB will start reading the output from the fast semihosting mechanism. Normally VisualGDB should handle this breakpoint internally and not show the “Sigtrap” message.

    If you get this breakpoint in the middle of the debugging session, most likely your program corrupts the memory and/or restarts unexpectedly. If it only happens during session initialization, please try comparing the full gdb logs for the normal session and the crashed session and check for any obvious differences (e.g. gdb errors). If you are not sure, feel free to post both logs here and we can take a look.

    #20775

    Yuriy
    Participant

    Hi,

    VisualGDB fails again, when I try to debug firmware. I collect and analyse logs, but I can’t undersand cause of fails.

    What actually fails? VisualGDB plugin, or VisualStudio itself, or new GCC toolchain from arm.com, or Segger drivers, or GDB server… I don’t know.

    Sequence always the same:
    1) JLinkGDBServerCL.exe fails first (as shown on attached fault_3_stop.PNG),
    2) then in “GDB Session” window appears progressbar,
    3) then I press button Stop debugging.

    These fails always unexpected, I can’t predict and reproduce it. Firmware always works fine without breakpoints, but when I set breakpoints and hit them, VisualGDB may crash (somtimes immediately after hit breakpoint, but usually after continue execution). What component most probably fails? Should I try another version of VisualStudio, toolchain or VisualGDB?

    New logs for crashed VisualGDB session also attached to this message.

    • This reply was modified 4 weeks ago by  Yuriy.
    • This reply was modified 4 weeks ago by  Yuriy. Reason: Attach "fault_3_gdb_session.txt" file
    • This reply was modified 4 weeks ago by  Yuriy. Reason: Attach logs from previous faults
    Attachments:
    You must be logged in to view attached files.
    #20783

    Yuriy
    Participant

    Also you mentioned that VisualGDB may stops on “hidden” breakpoints if my program corrupts the memory and/or restarts unexpectedly.

    What part of memory is used for GDB own purposes? What cause of restart will be unexpected for VisualGDB? (i.e. restart by watchdog, after hardfault, etc.)

    #20802

    support
    Keymaster

    Hi,

    This looks like an error in the J-Link gdb server (JLinkGDBServerCL.exe). Please contact Segger support regarding this as we don’t have access to the Segger GDB stub internals and are not able to troubleshoot its crashes.

    The memory we mentioned is used by the Semihosting Framework – it uses a part of the on-chip RAM to store the semihosting output (the debugger will read it in the background without stopping the target). This should not crash the J-Link gdb server, as all Fast Semihosting-related logic is handled by VisualGDB directly.

    #20827

    Yuriy
    Participant

    Hi,

    Thank you! Your suggestion about problems in Segger software was right. After updating to Segger J-Link V6.32 everything works fine.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.