Forum Replies Created
-
Posts
-
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.
Hi,
Thank you! Your suggestion about problems in Segger software was right. After updating to Segger J-Link V6.32 everything works fine.
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.)
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.
