[Yuriy]

No, we can’t change encoding of sources, because CP866 is used to communicate with third-party device. All messages in this device should be stored exactly in CP866.

We already have workaround – print short message in debug console (using latin characters), and then print actual data. So we can see, that data transferred. Anyway, thank you for your answer.

[Yuriy]

Hi,

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

[Yuriy]

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

[Yuriy]

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 6 years ago by Yuriy.
• This reply was modified 6 years ago by Yuriy. Reason: Attach "fault_3_gdb_session.txt" file
• This reply was modified 6 years ago by Yuriy. Reason: Attach logs from previous faults

Attachments:

You must be logged in to view attached files.

[Author]

Posts