STM32 ohne JTAG starten

100nF Kondensator an Reset?

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.

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

Nein, JP2 ist garnicht bestückt.

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.