STM8 / VS Code / GDB: "Exeption occurred" in der ersten Zeile beim Debugging

[Viktor B. (coldlogic)]

Hallo Leute,
Gleich zum Thema: hat jemand von euch erfolgreich eine Toolchain aus 
Visual Studio Code, SDCC, OpenOCD und GDB aufgebaut und zum Debuggen 
verwendet? Ich bin nach der Anleitung vorgegangen : 
https://github.com/hbendalibraham/stm8_started , ging auch beim ersten 
Mal gut. Beim zweiten allerdings (ein paar Tage und ein Update des VS 
Code später) zeigt VS Code mir beim Starten des Debuggers die erste 
Zeile des main.c rot markiert an mit der Aufschrift "Exeption occurred". 
Also von vorne, der Vollständigkeit halber:

- Ich starte OpenOCD mit

openocd -f interface/stlink.cfg -f target/stm8s207.cfg -c "init" -c "reset halt"

Das Terminal antwortet

Open On-Chip Debugger 0.10.0+dev-01337-g07df04b3-dirty (2020-07-23-19:53)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.org/doc/doxygen/bugs.html
adapter speed: 300 kHz

Warn : Transport "swim" was already selected
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst

Info : STLINK V2J35S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.230219
Info : clock speed 800 kHz
Info : starting gdb server for stm8s207.cpu on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, pc: 0x00006000
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections

Der lebt, also starte ich das Debuggen mithilfe von VS Code, der Eintrag 
in launch.json lautet wie in der verlinkten Anleitung. Das Terminal mit 
OpenOCD reagiert mit

Info : accepting 'gdb' connection on tcp/3333

Verbindung ist da, allerdings kann ich nichts debuggen, weil der PC auf 
der ersten Zeile verharrt, wo man ein Breakpoint setzen kann (also entry 
point). Das Debug Terminal des VS Code gibt gleich einen Wasserfall an 
Meldungen aus, diese hab ich dem Post angehängt. Es fällt auf:

warning: No executable has been specified and target does not support\ndetermining executable automatically.  Try using the \"file\" command

 Wie bitte? Ich kann nicht mal ein MI-Befehl dazu finden (vgl. 
https://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_228.html). Das 
sollte die VSC Extension (C/C++ 0.29.0) selber gemacht haben, und zwar 
wegen des Eintrags im launch.json "program": "${workspaceRoot}/main.elf" 
.

Warning: Debuggee TargetArchitecture not detected, assuming x86_64.

 WTF soll das denn sein? Ein paar Zeilen früher steht doch

1: (745) ->~"The target architecture is set automatically (currently stm8)\n"

 Dazu ist das stm8-gdb, der SOLL nur eine Arch können.

Hat jemand irgendwelche Ideen?
MfG, Viktor

[Markus F. (mfro)]

So wie ich das sehe, zeigt dein Log oben an, daß der Code richtig 
geladen und gestartet wird und auf dem Breakpoint stehen bleibt.

Der Crash kommt wohl eher aus dem VS Code.

[M. K. (Gast)]

Viktor B. schrieb:
> eine Toolchain aus
> Visual Studio Code, SDCC, OpenOCD und GDB

Ich habe dafür den IAR genommen, der bis 8K Codesize nix kostet.
Völlig problemlos und sehr entspannend.
Alles in einem Guß.

[Jim M. (turboj)]

Bei OpenOCD Problemen hilft oft der "-d3" Log.

Ansonsten sieht man nicht ob OpenOCD grade beschäftigt ist oder nicht...

[samuel (Gast)]

Ich kann dir sehr das Plugin Cortex-Debug für VS Code empfehlen. Das 
nutze ich abseits von Cortex-M Controllern auch für RISC-V problemlos, 
sollte also auch mit STM8 klar kommen. Es übernimmt auch das Starten und 
Stoppen von Openocd und ist ingesamt einfacher zu konfigurieren.

Dagegen hatte ich mit dem eingebauten VS Code C++ Debug, was ich zuerst 
für RISC-V nutzen wollte, nur Probleme.