Hallo,
ich habe Probleme mit meinem SAMD21 Xplainded board. Ich
programmiere/debugge bereits seit einem tag mit openocd und gdb und nun
auf einmal erhalte ich die meldung, dass der gdb nicht mehr auf das
device zugreifen kann:
1
blah@blah:~/Desktop/samd21/blinky-2302$ openocd
2
Open On-Chip Debugger 0.9.0 (2018-01-24-01:05)
3
Licensed under GNU GPL v2
4
For bug reports, read
5
http://openocd.org/doc/doxygen/bugs.html
6
Info : only one transport option; autoselect 'swd'
Aus den dmesg-Meldungen werde ich jetzt nicht direkt schlau aber ein
typischer Fehler, der bei OpenOCD in ein Timeout führt, ist wenn man die
SWD-Pins fälschlicherweise "umkonfiguriert".
Schau also mal ins Datenblatt deines Controllers, mache aus welche Pins
das sind und schaue dann mal scharf in deinen Quellcode ob du da nicht
irgendeinen der beiden Pins für etwas anderes hergenommen hast.
Bei STM32 ist eine sehr einfache Möglichkeit die SWD-Pins wieder in
einen funktionalen Zustand zu versetzen, den Controller per Boot-Pin in
irgendeinen ROM-Bootloader zu booten (sei es UART, USB, ganz egal), denn
innerhalb dieses ROM-Bootloaders sind die SWD-Pins eben für SWD
konfiguriert. Wie das jetzt im Detail bei Atmel aussieht kann ich nicht
sagen. ymmv
Hex danke für den Hinweis. Mit dem Microchip Studio habe ich ein
Beispiel auf den Controller schreiben können. Jetzt kann ich wieder ein
älteres programm mittel openocd drauf spielen.
PA30 und PA31 wären die PINS für das SWD, aber diese Überschreibe ich
nicht. Ich probiere mich gerade an dem TC3 (zunächste einfache PWM) aus
und wollte den TC3 auf PA14 legen. Kann es sein, dass der µC hängt, weil
ich z.b. den Clock garnicht richtig initialisiert habe?
openocd schrieb:> ann es sein, dass der µC hängt, weil> ich z.b. den Clock garnicht richtig initialisiert habe?
Klar kann das sein. Einige I/O Funktionen lösen einen Hardfault aus,
wenn man drauf zugreifen will bevor ihr Takt aktiviert ist.
Zumindest ist das bei STM so.
Ok, der OPENOCD kam per SWD nicht mehr auf den µC drauf. Was machen dann
solche tools wie microchip Studio anders, .. ich meine mit diesem Tool
habe ich irgendein beispiel drauf geflasht und erst danach konnte ich
OPENOCD wieder nutzen. Ginge das nicht auch mit OPENOCD?
Ja, das geht auch mit OpenOCD und wird oft als "connect under reset"
bezeichnet.
Das funktioniert so, dass man das Target resettet. Entweder macht man
das per OpenOCD mittels Resetleitung des Debug-Adapters oder man macht
das manuell per Reset-Taster des Targets.
Manuell geht das dann so:
- Resetbutton drücken und gedrückt halten
- OpenOCD Verbindung starten
- Resetbutton loslassen
Das funktioniert, weil die SWD-Pins nach einem Reset (bei mir bekannten
Controllern) "korrekt konfiguriert" sind und der Debug-Adapter so mit
dem Target kommunizieren kann, bevor der Code geladen wird, der die
SWD-Pins umkonfiguriert.
Christopher J. schrieb:> Ja, das geht auch mit OpenOCD und wird oft als "connect under reset"> bezeichnet.
Vorsicht: Funktioniert bei einigen µCs, aber bei vielen anderen wird mit
der Reset Leitung auch das Debug Interface abgeklemmt.
Ich bin jetzt zu faul nachzuschauen was beim AT91samD21 geht und was
nicht, eventuell kann der das.
ok vielen Dank für die Infos, ich werde es bei gelegenheit mal
ausprobieren, sicher werde ich den ein oder anderen Hard-fail sicher
nochmal produzieren ;D
Jim M. schrieb:> Christopher J. schrieb:>>> Ja, das geht auch mit OpenOCD und wird oft als "connect under reset">> bezeichnet.>> Vorsicht: Funktioniert bei einigen µCs, aber bei vielen anderen wird mit> der Reset Leitung auch das Debug Interface abgeklemmt.
Das ist ein guter Punkt aber im Fall des SAMD geben die OpenOCD-Quellen
direkt die Antwort:
1
# SAMD DSU will hold the CPU in reset if TCK is low when RESET_N
2
# deasserts (see datasheet Atmel-42181E–SAM-D21_Datasheet–02/2015, section 12.6.2)
3
#
4
# dsu_reset_deassert configures whether we want to run or halt out of reset,
# srst_pulls_trst is not configured here to avoid an error raised in reset halt
12
reset_config srst_gates_jtag
13
14
# Do not use a reset button with other SWD adapter than Atmel's EDBG.
15
# DSU usually locks MCU in reset state until you issue a reset command
16
# in OpenOCD.
Interessanterweise liegt da wohl auch was im Argen und wenn man sich die
älteren OpenOCD-Quellen anschaut, war dort die Resetkonfiguration leicht
verändert:
1
# SAMD DSU will hold the CPU in reset if TCK is low when RESET_N
2
# deasserts (see datasheet Atmel-42181E–SAM-D21_Datasheet–02/2015, section 12.6.2)
3
#
4
# dsu_reset_deassert configures whether we want to run or halt out of reset,
Da ich hier kein Xplained-Board zum testen rumfliegen habe, kann ich das
auch nicht genau nachvollziehen. Das kann ja bei Gelegenheit der TO mal
machen und berichten. Der Code stammt direkt aus dem target.tcl aus dem
OpenOCD-Mirror von hier:
https://github.com/ntfreak/openocd/blob/master/tcl/target/at91samdXX.cfg
Thread beobachten
Seitenaufteilung abschalten