Gehversuche mit JLinkGDBDebugServer auf da14695

[Chris K. (nitramin)]

Hallo,

ich versuche, um zunächst das System ansich zu verstehen, ein 
Beispielproject (bare_metal_blinky von DiagSemi für da1469x, KEIN 
FreeRTOS) auf einem da14695 USB DevKit zu debuggen. Build und flash 
funktioniert durch die im SDK mitgelieferten Python-Skripte sehr gut. 
Programm läuft, LED blinkt.

Nun geht's um's Debuggen. Das habe ich zunächst mit SmartSnippets 
(DiagSemi Brand von Eclipse) versucht. Der erstellt zunächst einen 
JLinkGDBServer mit den CLI args:

-if swd -device DA14695 -endian little -speed 8000 -port 2331 -swoport 2332 -telnetport 2333 -vd -ir -localhostonly 1 -singlerun -nogui

Das klappt sogar, wenn ich es manuell probiere, also die Verbindung wird 
hergestellt. Der Debugger von SmartSnippets/Eclipse landet dann jedoch 
eine Sekunde später in hw_watchdog.c in der Funktion 
hw_watchdog_handle_int(unsigned long *exception_args) und ich gehe mal 
davon aus, dass es sich dabei um eine Exception handelt.

Was kann da schief gelaufen sein? Ich finde ehrlich gesagt auf die 
Schnelle auch keine brauchbare Doku, für die Kombination aus 
JLinkGDBServer und arm-none-eabi-gdb. Also was könnte ich bspw. manuell 
im Client (arm-none-eabi-gdb) eingeben, um mich voranzutasten?
Ich bin hier gerade ziemlich ratlos, wo ich als nächstes weitersuchen 
kann.

Hat jmd. einen Tipp für einen Rookie in der Hinsicht?

Danke.

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Ist da evt ein Hardware Watchdog aktiv, den Du nicht bedienst?

[Jörg W. (dl8dtl) (Moderator)]

Chris K. schrieb:
> Ich finde ehrlich gesagt auf die Schnelle auch keine brauchbare Doku,
> für die Kombination aus JLinkGDBServer und arm-none-eabi-gdb.

Da brauchst du auch keine spezielle Doku. Das ist ein GDB Server, nicht 
viel anders (aus GDB-Sicht) als OpenOCD.

Uwe B. schrieb:
> Ist da evt ein Hardware Watchdog aktiv, den Du nicht bedienst?

Wäre auch meine Vermutung jetzt.

[Olaf (Gast)]

> Da brauchst du auch keine spezielle Doku. Das ist ein GDB Server, nicht
> viel anders (aus GDB-Sicht) als OpenOCD.

Es gibt aber eine. War aber imho relativ schwer zu finden.

Aber richtig, eigentlich sollte es reichen wenn der Server laeuft und 
der gdb damit connected.

> Ich bin hier gerade ziemlich ratlos, wo ich als nächstes weitersuchen
> kann.

Anleitung zu gdb lesen und im Terminal notfall die Assemblerbefehle 
einzeln durchsteppen.

Olaf

[Chris K. (nitramin)]

Vielen Dank erstmal an Euch.

Als ich nun eine Interaktion des Watchdogs des dialogs untersuchen 
wollte (nach etwas Einlesen in's Thema), musste ich nun feststellen, 
dass das Debugging plötzlich funktionierte. Mir ist allerdings nicht 
klar, was ich anders gemacht haben sollte, als bei meinen Versuchen vor 
einer Woche.

Der zu debuggende Code beginnt gleich mit

hw_watchdog_freeze();

und ich denke, dass eben damit der Watchdog verhindert werden soll.

Kann/muss ich demnach davon ausgehen, dass beim bei einer FreeRTOS 
Anwendung auf dem da1469x, die ja den Watchdog für die Überwachung der 
Tasks verwendet, eben der Watchdog zu Schwierigkeiten beim Debuggen 
führen kann??

Grüße,
CK

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Klar, unbehandelter Watchdog fuehrt zum Reset...