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?
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.
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
intmain(){
2
while(1)
3
asmvolatile("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
intmain()
2
{
3
volatileintrun=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