STM32Cube IDE zerstört im Debug STM32F103C8T6

Bastler schrieb:
> Leider scheint das Programm den Chip zerstört zu haben,
> nachdem ich versucht habe ihn über die Funktion "Debuggen" anzusprechen

Das kann nicht sein. Allerhöchstens kann der Inhalt vom Flash verloren 
gehen, dann hat man meist ein ursächliches Problem bei der 
Stromversorgung.

Du solltest dazu noch wissen, dass die SWD Schnittstelle auf mehrere 
Arten per Software deaktiviert werden kann. Dagegen hilft:

Stelle man den Boot0 Jumper auf "Bootloader" ein und mache dann einen 
Reset. Dann kannst du wahlweise seriell oder per SWD wieder drauf 
zugreifen. Danach stellst du den Jumper zurück.

Ansonsten: Schaltplan und Fotos vom Aufbau zeigen.

Leider hat die Platine keinen BOOT Jumper, das ist eine kommerzielle 
Platine deren Schaltplan oder Layout ich nicht habe. Das einizge was 
noch angezeigt wird, wenn ich z.B. über das STM32 ST Link Utility 
versuche, den Chip anzusprechen ist "Can not connect to target!
                  If you're trying to connect to an STM32W1xx device, 
please select Normal or HotPlug mode from Target->Settings menu."

Was auch immer da passiert ist, der Mikrokontroller ist komplett tot, 
die LED die normalerweise blinkt wenn er aktive ist leuchtet nicht mehr, 
der Chip reagiert auf nichts mehr. Keine Ahnung warum. Stromversorgung 
ist in Ordnung, daran dürfte es nicht liegen.

Bastler schrieb:
> Leider hat die Platine keinen BOOT Jumper,

Andere Möglichkeit ist die "Connect under Reset" Option in der Software 
(ST-Link Utility oder STM32 Cube Programmer).

Dazu musst du den Reset Knopf gedrückt halten, dann die SWD Verbindung 
aufbauen und dann im richtigen Moment wieder loslassen. Das übst du aber 
besser vorher an einem Chip, der noch funktioniert.

Wie mache ich das wenn die Platine keinen RESET Knopf hat?

Ich sehe gerade, dass die Option "Connect under Reset" nur im ST-Link 
Utility existiert. Schade, dass der neue Cube Programmer das nicht kann.

> Wie mache ich das wenn die Platine keinen RESET Knopf hat?

Vorschlag: Einen Reset-Knopf hinzufügen.

Also kurzum da gibt es ohne Reset Knopf keine andere Möglichkeit mehr?

Bastler schrieb:
> Also kurzum da gibt es ohne Reset Knopf keine andere Möglichkeit mehr?

Du siehst doch, dass du deinen Chip gerade nicht ansprechen kannst. Also 
musst du ihn aus diesem Zustand heraus holen, und das geht wohl nur über 
einen Reset zuverlässig wenn man keinen Boot Jumper hat.

Was ist denn daran so schwer, einen Reset-Knopf hinzuzufügen? 
Normalerweise ist der Pin am SWD Stecker mit herausgeführt, aber bei Dir 
wohl nicht, sonst hättest du das Problem vom Eröffnungsbeitrag nicht.

Hast du denn die Firmware überhaupt als Quelltext oder Binary vorliegen? 
Wenn das nicht der Fall ist, brauchst du gar nicht weiter machen. Denn 
die kaputte Firmware zu debuggen wird dich auch nicht weiter bringen.

Ich hab die Firmware als .hex da, die kann ich jederzeit wieder drauf 
bekommen, aber nicht ohne den Chip wieder anzusprechen. Das Problem ist, 
wie verhindere ich dass mir wenn ich es schaffe den Chip aus diesem 
Zustand zu kriegen die Cube IDE das sofort wieder macht? Ich will den 
Chip nur beobachten, beim arbeiten, nicht irgendwas flashen, aber genau 
das macht die IDE offenbar ohne dass ich es will, dabei wird dann wohl 
auch der Debug Port als Ausgang gesetzt. Wie verhindere ich dass die IDE 
das macht? Die soll mir den Chip in ruhe lassen und nur beobachten, 
nichts flashen oder schreiben.

Mit dem RESET Pin des Prozessors ist übrigens ein Kondensator verbunden. 
Ich schließe den Üin jetzt mal mit GND Kurz, und sehe ob sich der 
Controller denn zur Kommunikation überreden lässt.

Im Normalfall hat SWD immer funktioniert. Leider scheint mir die IDE das 
umzukonfigurieren. Der Chip hat sich immer per SWD konfigurieren lassen, 
auch flashen, und kommunizieren, mit dem STlink Utility hat das immer 
funktioniert. Jetzt will ich aber mal sehen was die Firmware macht, aber 
die IDE versteht das "Du sollst nur anzeigen was der Chip tut" als "Du 
sollst irgndwas flashen und dann anziegen was das auf dem Chip tut.

So, Chip geht wieder, RESET auf LOW gezogen mitm Jumper Kabel und neu 
geflasht -> Chip verhällt isch normal. Jetzt müsste ich nurnoch wissen 
wie ich es schaffe dass ich in den RAM sehen kann während der arbeitet, 
ohne dass mir die IDE wieder den Pin umkonfiguriert, so scheint es 
nämlich wohl zu sein, der Chip lässt sich mit dem ST Link Utility sogar 
ohne reset per HotPlug packen, nur der Debugger der IDe versucht immer 
was zu builden, flasht das dann irgendwie und will es dann debuggen, er 
lässt mir also das Programm was auch dem Prozessor ist nicht in Ruhe. 
Kann es sein dass das Debuggen in der IDE nur bei Programmen geht deren 
Source Code vorhanden ist?

Bastler schrieb:
> Das Problem ist,
> wie verhindere ich dass mir wenn ich es schaffe den Chip aus diesem
> Zustand zu kriegen die Cube IDE das sofort wieder macht?

Warte doch erst einmal ab, ob das Problem überhaupt wiederholt auftritt.

Soweit ich sehen kann ist Dir das genau einmal passiert. Daraus 
abzuleiten, dass dies jetzt immer wieder passieren wird und irgednd 
etwas grundsätzlich kaputt sei, finde ich verfrüht.

> Mit dem RESET Pin des Prozessors ist übrigens ein Kondensator verbunden.
> Ich schließe den Üin jetzt mal mit GND Kurz, und sehe ob sich der
> Controller denn zur Kommunikation überreden lässt.

Ja, mache das.

Bastler schrieb:
> nur der Debugger der IDe versucht immer
> was zu builden, flasht das dann irgendwie

Du musst den Debugger nur mit dem µC verbinden. Wenn du auf den grünen 
Käfer klickst, wird normalerweise das aktuelle Programm compiliert, 
hochgeladen, gestartet und debuggt. Du willst aber einfach nur den 
Debugegr connecten. Wie das geht, weiß ich gerade auch nicht auswenddig. 
Ich sitze im Büro, da kann ich es leider nicht nachschauen.

> Kann es sein dass das Debuggen in der IDE nur bei Programmen
> geht deren Source Code vorhanden ist

Hoffentlich nicht. Bei einer älteren Variante der IDE (System Workbench 
for STM32) ging das jedenfalls so wie du es brauchst.