OpenOCD startet plötzlich nicht mehr, Boards defekt

[Peter (Gast)]

Hallo,

ich hatte gestern einen Thread wegen Problemen mit CubeMX und I2C 
aufgemacht:
Beitrag "CubeMX und HAL - I2C hängt sich auf"

Leider musste ich kurz darauf feststellen (nachdem ich mein Ubuntu in 
der CubeMX Umgebung upgedated hatte), dass auch meine 
JTAG-Programmierung nicht mehr funktioniert. Deshalb auch dieser Thread.

Folgendes ist passiert:
Ich habe zur Zeit zwei Entwicklungsumgebungen (CubeMX unter Ubuntu 16 
und die StdPeripLib unter Ubuntu 16 in der VirtualBox), da ich von der 
Standard Peripheral Library auf die HAL Treiber und CubeMX umsteigen 
möchte.

Teil 1.1:
Die I2C Schnittstelle läuft bei der StdPeriphLib ohne Probleme. Das 
Programmieren per JTAG und OpenOCD auch. Nach dem Wechsel in die 
CubeMX-Umgebung habe ich getern den halben Tag vergeudet um die I2C 
Schnittstelle zum laufen zu bringen (leider bisher ohne Erfolg, aber das 
ist eine andere Geschichte).
Plötzlich musste ich feststellen, nachdem ich ein kleines Test-Projekt 
ertsellt hatte, dass auch die JTAG-Programmierung nicht mehr 
funktioniert (Bild 1).


Teil 1.2:
Ich wechsel also in meine andere Entwicklungsumgebung (die mit der 
StdPeriphLib) und versuche da zu flashen. Funktioniert auch nicht mehr 
(Bild 1).

Fazit 1: Board defekt, da ich ja an den OpenOCD Einstellungen 
zwischendurch nichts geändert habe.

Teil 2.1:
Zum Glück habe ich noch 9 weitere STM32F103 China-Boards und nehme mir 
also ein Neues. Diesmal aber zuerst in der StdPeriphLib-Umgebung. Und 
siehe da: Es lässt sich ohne weiteres programmieren.

Teil 2.2:
Ich gehe also wieder zurück in meine CubeMX-Umgebung und versuche 
erneut, OpenOCD zu starten. Es funktioniert (Bild 3). Den Chip zu 
löschen funktioniert auch (Bild 4). Als nächstes wieder das Flashen - 
und die Kiste schmiert ab (Bild 5).

Fazit 2:
Entweder ist das .bin File meines Test-Projektes zum Flashen derart 
fehlerhaft vom CubeMX erstellt worden (mit meiner bescheidenen Mithilfe 
natürlich), dass nach dem Flashen (oder auch schon während dessen), der 
STM32 abstürzt, oder mein Problem liegt am Update meines Ubuntu.
Übrigens: Das Board war wieder kaputt. Es hat jetzt auch in der 
StdPeriphLib-Umgebung nicht mehr funktioniert.

Nächster Versuch 1.1:
Jetzt nehm ich mal das binary file aus der StdPerphLib-Umgebung und 
versuche es in der CubeMX Umgebung zu flashen (zuerstmal brauch ich 
dafür ein weiteres China-Board).
Und siehe da: Es geht!

Gesamt-Fazit: Ich habe mir jetzt 4 Boards zerstört, weil der CubeMX 
fehlerhaften Code generiert. Zugegeben, ich habe die Einstellungen 
selber vorgenommen. Diese sind aber so simpel, dass da eigentlich nichts 
passieren dürfte (lediglich I2C1 aktiviert und RCC).
Ausserdem bin ich der Meinung, dass man den CubeMX gerade deshalb nimmt, 
um beim Setup der Hardware unterstützt zu werden, und daher sollteein 
solches Verhalten auch ausgeschlossen sein - egal wer vor dem PC sitzt.

Wie das mit dem CubeMX bei mir weitergeht? Ich hatte zuvor ein paar 
Tests erfolgreich damit laufen. Ausserdem habe ich noch ein paar Boards 
übrig - ich werde mir das alles also nochmal genauer anschauen.

Gruß Peter

[Niklas G. (erlkoenig)]

Hast du im CubeMX vielleicht JTAG/SWD komplett abgeschaltet (unter 
"SYS")? Oder die "WFI"-Instruktion benutzt? Die versetzt auch den 
JTAG-Teil in den Sleep-Modus, sodass man nur noch der Reset-Pin hilft.

Du hast doch anscheinend einen J-Link. Benutze den doch mal mit der 
Original-Software von Segger. Eigentlich ist das Teil gut dafür geeignet 
mit solchen Problemen umzugehen - benutze den Reset-Modus 3, das 
funktioniert eigentlich immer solange beide Reset-Leitungen verbunden 
sind und man nicht gerade den Reset-Pin selbst abgeschaltet hat.

Alternativ halte den Reset-Knopf gedrückt, dann erst das Board 
einschalten und dann per OpenOCD verbinden.

[A. B. (Gast)]

Höchstwahrscheinlich nicht "kaputt", sondern in der geflashten Firmware 
die JTAG-Pins umkonfiguriert.

Ein "connect under reset" sollte reichen. Wenn der JTAG-Adapter etc. das 
nicht unterstützt, manuell Reset-Taste drücken (oder mit 'nem Jumper) 
und HALTEN bis openOCD verbunden und den uC gestoppt hat.

[Peter (Gast)]

Hallo,

danke für die Tipps. Leider scheint das nicht zu helfen (RESET halten 
und warten bis verbunden ist, Bild 6).

Die original Software von Segger werde ich jetzt nochmal probieren und 
melde mich dann.

Gruß Peter

[A. B. (Gast)]

Das JTAG-Interface arbeitet ja (anfangs) noch, daher wird kaum etwas 
kaputt sein.

Da das löschen noch klappt(e?) wär' da noch ein Gedanke: Was steht in 
der "kaputten" Firmware im Reset-Vektor (0x08000004)? Also im .bin?

[Peter (Gast)]

A. B. schrieb:
> Da das löschen noch klappt(e?) wär' da noch ein Gedanke: Was steht in
> der "kaputten" Firmware im Reset-Vektor (0x08000004)? Also im .bin?

Das Löschen funktioniert eben nicht mehr. Nur bei einem neuen Board ist 
Anfangs das Löschen noch möglich. Nach dem Flashen geht leider garnix 
mehr. Das hab ich vlt. etwas unverständlich ausgedrückt.

Niklas G. schrieb:
> Du hast doch anscheinend einen J-Link. Benutze den doch mal mit der
> Original-Software von Segger.

Auch darüber habe ich keinen Zugriff mehr. Es kommt dann eine nichts 
sagende Fehlermeldung,  Error: cannot connect to device, oder so 
ähnlich.

[Johannes S. (Gast)]

Wenn die JTAG/SWD Pins im Programm umkonfiguriert werden hilft auch oft 
in den Bootloader zu booten.
Startprobleme kann es auch geben wenn man den Takt falsch programmiert.

[Max D. (max_d)]

Boot-Jumper setzen, dass er den bootloader statt der fw lädt und dann 
nochmal probieren.
Hat mir schon paar mal den A**** gerettet.

Ps: Frühere cubemx Versionen hatten einen Bug in der Konfiguration der 
remap register und haben damit bei der Benutzung von pin-remapping je 
nach Hardwaremodul das swd gekillt.
Die neueste Version ist gefixt.

[Peter (Gast)]

Johannes S. schrieb:
> Wenn die JTAG/SWD Pins im Programm umkonfiguriert werden hilft auch oft
> in den Bootloader zu booten.
> Startprobleme kann es auch geben wenn man den Takt falsch programmiert.

Max D. schrieb:
> Boot-Jumper setzen, dass er den bootloader statt der fw lädt und dann
> nochmal probieren.

Zwei konnte ich retten - eins ist kaputt.

Danke!