Hallo :) Ich habe einen STM32F105 programmiert und ein Problem ihn ohne JTAG zu starten. Ich benutze Eclipse und OpenOCD zum flashen und debuggen. Solange der Olimex JTAG dran ist, läuft alles wunderbar. Aber wenn ich das Programm flashe, den Strom wegnehme und den JTAG abziehe, dann läuft er genau 1x an. Nochmal Strom weg und wieder ran und nichts geht mehr. Er reagiert auch nicht auf Reset. Ich muss den JTAG wieder anschließen und mindestens Reset Run ausführen. Das kann doch nicht normal sein? Meine AVRs laufen immer an, sobald das Programm im Flash ist und man Reset auf low legt. Reset hat einen 10k Pullup gegen 3,3V (hab ich jetzt nachträglich rein, bringt aber keine Änderung). BOOT1 ist direkt auf Masse, BOOT0 mit 10k gegen Masse. JTAG hat keine weiteren Pullups, da nicht nötig. 8MHz Quarz an OSC. Bin ratlos....
A. K. schrieb: > 100nF Kondensator an Reset? Sowas ist heutzutage bei keinem Microcontroller mehr notwendig. Die Controller haben alle einen per Timer gesteuerten Power-On-Reset. Ich habe genügend Schaltungen mit dem STM32 (und auch mit anderen Cortex-M3) aufgebaut, ein Kondensator am Reset ist nie erforderlich. Erwin
Glaube ich gern, aber schaden wird er auch nicht und hier besteht ein Problem, also wär's einen Versuch wert. ST selbst sieht ihn zumindest in Verbindung mit einem Reset-Taster in den Beispielbeschaltungen stets vor.
Ja. 100nF Reset gegen Masse. Nur an VBat hab ich nichts. Aber das wird ja nicht der Grund sein, dass er nicht startet? Hab VBat auch gerade testweise gegen 3,3V gelegt ohne Änderung.
Zeig mal die Schaltung. Als Bild, nicht in Prosa. Und schau mal in die AN2586 rein.
Angehängte Dateien:
-
stm32.png
17 KB
Mir ist gerade aufgefallen, dass "reset run" nicht hilft zum neustarten. Ich muss das Teil komplett neu flashen... Die Befehle in meiner openocd_reset_run.cfg: init reset run shutdown VBat ist jetzt permanent gegen 3,3V wie in AN2586 "highly recommended". Ich habe das Problem mit mehreren Boards. Es sollte also nicht an einem kaputten ARM liegen.
Ein LC-Filter an Vdda ist ok, aber vor der gesamten Versorgung ist er eher kontraproduktiv, zumal wenn dort der empfohlene 10µF Elko fehlt.
Florian Micro schrieb: > Mir ist gerade aufgefallen, dass "reset run" nicht hilft zum neustarten. > Ich muss das Teil komplett neu flashen... Das freilich klingt irgendwie nach Selbstmordprogramm.
Ich hab die Spule jetzt mit 0R gebrückt und den 10µF rein. Mir ist auch aufgefallen, dass es keinen Unterschied macht, ob der JTAG dran ist oder nicht. 1x Strom weg und der ARM startet nicht mehr. In den errata konnte ich nichts dazu finden. Wäre auch etwas übel.
Es muss wohl meine SW sein. Habe gerade ein Programm von Martin Thomas probiert und damit startet er nach Reset und Strom weg neu. Man lernt nie aus... Kann mir vielleicht jemand sagen, an welcher Stelle ich gucken sollte? Danke :)
Könntest die Suche etwas erleichtern, indem du das Program rausrückst. Die Glaskugeln sind stets in Reparatur, grad unwillig oder haben Migräne. Wenn es dafür zu gross ist, dann solltest du ohnehin selbst Hand anlegen und sukzessive einzelne Teile deaktivieren. Wenn's dann plötzlich mal funktionieren sollte, dann bist du einen Schritt weiter. Wenn nicht, dann ist es irgendwann klein genug um es auf die Welt loslassen zu können. Bei den LPC2000 hatte jemand mal unfreiwillig rausgefunden, wo die undokumentierten Register für die Flashprogrammierung sitzen.
Ich hab mir vermutlich den RAM versaut mit meinen Debug Meldungen.
void u_putchar(char c) {
// Loop until USART1 DR register is empty
while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET) {
;
}
USART_SendData(USART1, c);
}
void uputs(const char *c) {
while(*c) u_putchar(*c++); // send string char by char
}
So gebe ich dann Debug Meldungen aus:
uputs("K pressed long");
Damit scheinen die im RAM zu landen. Wie kriege ich die in den Flash?
Das geht nicht:
uputs((const char *)"K pressed long");
Nur das:
const char *c = "K pressed long";
uputs(c);
Aber das ist etwas umständlich zu schreiben.
Beim AVR hab ich PSTR benutzt. Aber der hat auch ne andere Architektur.
Bin noch etwas Newbie mit den ARMs ;)
Aber danke für die geduldige Hilfe!
Florian Micro schrieb: > Damit scheinen die im RAM zu landen. Sollten sie nicht. Aber jetzt kommen wir der Sache vielleicht näher. Was wo landet wird vom Linker-Script bestimmt. Wenn das falsch ist und Code/Daten ins RAM schreibt (in Entwicklung nützlich), du es aber gerne im Flash hättest, dann ist spätestens nach Strom abschalten Schicht im Schacht.
Hm, ja. Das hat auch nichts gebracht: const char *c = "K pressed long"; uputs(c); Erst wenn ich die 4 Debugmeldungen komplett auskommentiere, läuft es. Dabei werden die Debugmeldungen normal nicht gesendet. Die bringen also irgendwo den Speicher zum Überlaufen. Ich habe 128k Flash und 32k RAM. Das Linkerskript im Anhang ist das von Martin, nur auf 32k RAM geändert. Und hier die Ausgaben vom Compiler: Damit gehts: section size addr .text 58508 134217728 .ARM.exidx 8 134276236 .rodata 6408 134276248 .data 1864 536870912 .bss 608 536872776 ._usrstack 256 536873384 .comment 1470 0 .debug_aranges 5064 0 .debug_pubnames 15352 0 .debug_info 75297 0 .debug_abbrev 13535 0 .debug_line 28134 0 .debug_frame 18544 0 .debug_str 24633 0 .debug_loc 51536 0 .debug_ranges 5168 0 .ARM.attributes 49 0 Total 306434 Damit nicht: section size addr .text 58572 134217728 .ARM.exidx 8 134276300 .rodata 6488 134276312 .data 1864 536870912 .bss 608 536872776 ._usrstack 256 536873384 .comment 1470 0 .debug_aranges 5064 0 .debug_pubnames 15352 0 .debug_info 75297 0 .debug_abbrev 13535 0 .debug_line 28134 0 .debug_frame 18544 0 .debug_str 24633 0 .debug_loc 51536 0 .debug_ranges 5168 0 .ARM.attributes 49 0 Total 306578
Ok! Wenn es mit dem Programm von Martin Thomas und dem gleichen Linkerscript läuft, kann es ja schon mal nicht daran liegen.
Könnte schon. Wenn die Speichergrenzen falsch definiert sind. Mein Programm läuft ja auch, bis ich zu viele Debugmeldungen programmiere. Kenne mich damit leider nicht aus und das Linkerskript sieht nach Studieren der Datenblätter ok aus.
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.