Hallo, ich möchte gern mit Hilfe von CooCox eine STM32F1 Controller flashen und debuggen. In der Vergangenheit hat es immer sehr gut und zuverlässig funktioniert. Leider seit gestern nicht mehr. Ich habe seit dem einige Tests durchgeführt, deren Ergebnisse mir aber komisch vorkommen. Über das Oszi sehe ich, dass der Reset Pegel beim Schreiben auf den Controller über CooCox die gesamte Zeit High bleibt. Der Fehler in der SW wird mir mit Error: Flash driver function execute timeout angezeigt. In einigen Fällen hilft das Ziehen des USB Steckers. Versuche ich anschließend in der gleichen Konstellation nur mit den Tool STM32-ST-Link Utility auf den Controller zuzugreifen. Klappt alles. Das Reset Signal ist kurzfristig low und anschließend wird das Programm eingespielt. Gleiches Verhalten sehe ich auch in CoFlash. Ich verwende den ST Link V2 mit dem neusten Treibers sowie den Controller STM32F103 RB. CooCox habe schon 2x neu heruntergeladen und installiert. Für hilfreiche Kommentare zur Lösung des Problems wäre ich sehr dankbar.
Greenhor schrieb: > Über das Oszi sehe ich, dass der Reset Pegel beim Schreiben auf den > Controller über CooCox die gesamte Zeit High bleibt. Welches? Das NJTRST oder NRST Signal?
@ Dr. Sommer: Das Oszi ist am Pin NRST des SWD Connectors angeschlossen.
Greenhorn schrieb: > Das Oszi ist am Pin NRST des SWD Connectors angeschlossen. Da ist es im Allgemeinen bei ARMv7M egal wenn der nie auf "low" geht, da die über JTAG/SWD resettet werden. Bei den STM32 gibt es aber leider einen Hardware-Bug, der unter bestimmten Bedingungen das Resetten über NRST erforderlich macht. Musst du mal in den Einstellungen von CooCox schauen, ob das "Connect under Reset" oder so kann.
Gefunden habe ich die Einstellung noch nicht in CooCox.Was mir etwas verwundert ist die Tatsache dass es knapp 1Jahr zuverlaessig funktioniert hat.
Der Hardware-Bug der STM32 tritt nicht immer auf, deswegen ist "normalerweise" der Reset gar nicht notwendig. Typischerweise wird der Reset dann gebraucht, wenn das Programm auf dem Controller gerade ein "wfi" oder "wfe" ausführt (gibt vermutlich aber noch andere Gründe). Kannst ja mal testweise ein Programm drauf flashen, was diese Instruktionen nicht ausführt, und dann CooCox ausprobieren... Probiere auch mal direkt vor dem Flashen/Debuggen den Reset manuell zu betätigen, das kann da auch helfen.
Hi, bin an einem HW Reset Signal beim Debuggen unter CooCox starkt interessiert, da ohne erst mal lustig einfach schon mal die schon geflashte Firmware gestartet wird bis der SWD Reset greift. Da ist sehr störend beim Entwickeln einer EEPROM Simulation. Als Notnagel habe ich bisher eine Taster Run-Abfrage benutzt. Nur je nach Hardware habe ich aber keinen freien bit-Port. Hat jemand Erkenntnisse ob und mit welcher SWD-Link Hardware der Reset unterstützt wird? Bisher benutzte ich ein discovery Bord als SWD Link. Das ST-Link Utility benutzt den HW Reset, es geht also generell. Gruß Ingo
Ich arbeite jetzt schon einige Jahre mit den STM32F103s und habe noch nie irgendwelche Probleme mit dem JTAG port so wie Du damit gehabt. Das einzige was mir aufgefallen ist, dass, wenn ich die St Flash utility verwende um den MCU mit dem Release Code im geschütztem Status zu laden, dass ich nach dem Flashen einen Power Cycle machen muss. Mit der Flash Utility Reset Steuerung geht das nicht. Dann hängt der MCU bleibend nach dem Flashen. Geht es Dir ähnlich? Ich verwende auch den St-Link V2 in SWD mode. Ist es möglich dass es an Deiner verwendeten Schaltung irgendwie liegt? Bei mir hielt ich mich immer an die von Olimex gebrauchte JTAG Beschaltung mit den pullups und pulldown am clk. Wie gesagt bei mir habe ich absolut noch nie Probleme gehabt. Das gilt für mich fuer die RB und VE Typen sowohl als auch für die F407er. Mfg, Gerhard
Ingo Stahl schrieb: > Hat jemand Erkenntnisse ob und mit welcher SWD-Link Hardware der Reset > unterstützt wird? Der Segger J-Link kann das, der hat Pins für beide Reset-Leitungen und einen Spezial-STM32-Modus um das Problem zu umgehen. Der ist onehin viel besser als der ST-Link, da u.a. wesentlich schneller. Gerhard O. schrieb: > Ich arbeite jetzt schon einige Jahre mit den STM32F103s und habe noch > nie irgendwelche Probleme mit dem JTAG port so wie Du damit gehabt. Interessant. Flashe mal dieses Programm drauf:
1 | int main () { |
2 | while (1) |
3 | asm volatile ("wfi"); |
4 | }
|
Mache einen Power-Cycle, und versuche dann per ST-Link drauf zuzugreifen (ohne den Reset-Taster zu benutzen). Ich nehme an den Screenshot wie im Anhang kennst du dann auch nicht? Ob der ST-Link funktioniert scheint sehr vom Glück anzuhängen... Meine Uni hat STM32L100 Discovery-Boards für Praktika angeschafft, ich hatte aus Gewohnheit das "wfi" in einem Programm verwendet, und prompt beschwerte sich der nächste Benutzer des Boards dass sich der Controller über den eingebauten ST-Link nicht mehr flashen ließe... Gerhard O. schrieb: > Bei mir hielt ich mich immer an die von Olimex gebrauchte JTAG > Beschaltung mit den pullups und pulldown am clk. Kannst die mal zeigen? Wie sind die Reset-Leitungen verschaltet?
Dr. Sommer schrieb: > Gerhard O. schrieb: >> Bei mir hielt ich mich immer an die von Olimex gebrauchte JTAG >> Beschaltung mit den pullups und pulldown am clk. > Kannst die mal zeigen? Wie sind die Reset-Leitungen verschaltet? Mache ich - aber erst ein bischen später, kann jetzt gerade nicht zu meinem PC und habe nur den iPAD zur Verfügung.
Der ST-Link auf dem STMF0 discovery hat auch einen Reset Anschluss, nur der wird von CooCox nicht bedient. Auch wenn man in der IDE Debug-Konfiguration der HWReset aktiviert ist. Sonst funktioniert ja alles. Gestört hat das als ich eine für meine Zwecke spezielle EEPROM Simulation geschrieben habe, die auch Strukturen enthält. Gruß Ingo
Dr. Sommer schrieb: > Mache einen Power-Cycle, und versuche dann per ST-Link drauf zuzugreifen > (ohne den Reset-Taster zu benutzen). > Ich nehme an den Screenshot wie im Anhang kennst du dann auch nicht? Ob > der ST-Link funktioniert sch Habe ich nie bei mir bekommen.
Was mir noch einfällt: ich kann meine Schaltung entweder mit dem Board Reset Taster oder vom CooCox IDE resetten. Das geht einwandfrei. Wie ist das bei Euren Boards? Mit den Discovery boards arbeite ich nie. Ich habe nur die Eigenbauten zur Verfügung. Mfg, Gerhard
Ich habe eigene Hardware in Gebrauch in Verbindung mit dem ST-Link Target Anschluss eines meiner discovery Boards. Der Reset per SWD hat bisher auch immer funktioniert. Mein erstes STM32F1 discovery hat gar keinen Reset Pin am Target Anschluss, aber das später gekaufte STM32F0discovery hat diesen. Bei den normalen Anwendungen ist es ja kein Problem wenn beim Debuggen ein Teil des vorherigen, schon im Flash bestehenden Programms durchlaufen wird, bis dann der SWD Reset zuschlägt und die IDE beim main Entry Breakpoint steht. Alle wichtigen Register und RAM Inhalten sind ja richtig neu aufgesetzt. Nur wenn dadurch Veränderungen im Flash Bereich der EEPROM-Simulation stattfinden, weil die EEPROM Init_Funktion schon aufgerufen wurde, ist das ärgerlich wenn man genau diese Debuggen will. Gruß Ingo
Der Discovery-ST-Link hat einen Reset Ausgang, aber den scheint es nicht anzusteuern, selbst wenn man es in der Software aktiviert. Habe es allerdings noch nicht per Scope verifiziert. Wenn man den Reset-Button, der mit dem selben Eingang verbunden ist, direkt vor dem JTAG-Verbindungsversuche betätigt, gehts... Bei o.g. Anekdote wurde übrigens Keil µVision verwendet, also quasi die Referenzimplementierung, und selbst damit gabs das Problem.
Ich habe es mit dem LA überprüft. Beim Debug Start mit der CooCox IDE kommt kein Reset, trotz HW Reset Einstellung in der Debugger Konfiguration. Aber greift man per ST-Link Utility auf den STM32 per SWD zu, so kommt ein Reset Signal. Gruß Ingo
Hallo, ich programmiere gerade einen StM32F0306 (Wobei das denk ich egal ist) und muss die SWD Pins aus Ausgänge nutzen. Dadurch geht das Programmieren, wie es scheint, nur noch mit einem HW Reset. Ich Prgrammiere auch mit Coocox und habe den ColinkEx und ST-Link probiert. Bei beiden wird dummerweise kein HW Reset ausgelöst. Ich habe auch schon die verschiedenen Reset Optionen ausprobiert, ohne Erfolg.... Hat jemand eine Idee wie man das doch noch irgendwie unter Coocox einschalten kann?
Ingo Stahl schrieb: > Als > Notnagel habe ich bisher eine Taster Run-Abfrage benutzt. Nur je nach > Hardware habe ich aber keinen freien bit-Port. So ein Problem hatte ich letztens auch, aber mit einem anderen Controller. Meine Loesung war folgende:
1 | int main() |
2 | {
|
3 | volatile int run = 0; |
4 | while(run == 0); |
5 | ...
|
6 | }
|
So wurde das "eigentliche Programm" erst gestartet, wenn ich mittels Debugger die Variable "run" auf einen anderen Wert gesetzt habe. Nur so als Anregung. LG
Bitte 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.

