Hallo, Habe mir mal die STM32 Cube IDE heruntergeladen weil ich einen SZM32F103C8T6 beim Arbeiten beobachten wollte, und dazu dessen RAM anschauen wollte während er läuft. Leider scheint das Programm den Chip zerstört zu haben, nachdem ich versucht habe ihn über die Funktion "Debuggen" anzusprechen fährt der Chip nicht mehr hoch und ist nicht mehr erreichbar, auch nciht mit dem STM 32 ST Link Utility???!!! Ich kapiers nicht, die SWD Kabel waren richtig angeschlossen, aber der Chip ist seit dem Versuceh mit dem Debuggen per Cube IDE vollkommen tot. Als Adapter wurde ein STlink V2 ISOL benutzt.
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.
Das macht deine Firmware die sperrt vermutlich SWD. Ich würde das zumindest machen. Wenn ich Hersteller der (Roller) Firmware wäre, würde ich alles unternehmen um das Debuggen zu erschweren. Es bleibt dir vermutlich nichts anderes übrig als Reset / Boot nachzurüsten
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?
Kann es sein das dein Problem folgendes ist ? bin auch darauf reingefallen, Beitrag "STM32 CubeIDE und STLink V2 Debugger instabil"
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.