OpenOCD startet plötzlich nicht mehr, Boards defekt

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