Forum: Analoge Elektronik und Schaltungstechnik Step-Down-Regler ist zu langsam


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von lars (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze zum ersten Mal einen Step-Down-Regulator (TPS62082 von TI), 
um u.a.  einen STM32 mit 3.3V zu versorgen.

Nun startet der STM32 bei Anlegen der Versorgungsspannung von 5V in ca. 
70% der Fälle nicht; ein manueller Reset (NRST auf LOW) funktioniert 
dann aber.

Im ST-Forum wurde vorgeschlagen, dass die Spannung zu langsam 3.3V 
erreicht. Man sieht das auch schön im angehängten Oszi-Screenshot.  Der 
Regler braucht über 1ms!  Laut Datenblatt sollte er das in 40us + 
10mV/us schaffen, bei 3.3V also in weniger als 400us.

Wieso braucht der Regler so lange?  Man sieht ja einen Knick, der im 
Datenblatt so nicht vorkommt.  Kann dies vielleicht ein Lötproblem sein?
Kann ich diesen Regler durch andere Größen bei Spule/Kondensatoren 
schneller machen?

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ab dem Knick fliesst neben dem Strom zum Aufladen des 
Spannungsreglersausgangskondensators auch noch Strom auf 
Verbraucherseite, weil dein STM anfängt zu schwingen (BOD)  oder ein 
andere IC (Überschreitung von Schwellspannungen) zur Stromaufnahme 
beiträgt ?

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja, das ist sehr gut möglich! Mit einem LD Linearen Regler hatte ich das 
Problem allerdings nicht.

Was könnte ich jetzt dagegen tun? Eine Diode einbauen, die erst ab 3.2V 
durchschaltet? Bei bis zu 1.2A Strom wird das vielleicht schwierig. 
Einen schnelleren Regler verwenden?

von M. K. (sylaina)


Bewertung
1 lesenswert
nicht lesenswert
Eine Lösung könnte sein den STM mittels diskreten BOD im Resetmode zu 
halten bis eine Mindestspannung erreicht ist.

von Michael M. (michaelm)


Bewertung
0 lesenswert
nicht lesenswert
M. K. schrieb:
> Eine Lösung könnte sein den STM mittels diskreten BOD im Resetmode zu
> halten bis eine Mindestspannung erreicht ist.

Würde ich auch so machen. Optimal wäre, wenn der Eingang 
Schmiittriger-Vehalten hätte. Dann reicht ein simples RC-Glied.

lars schrieb:
> Laut Datenblatt sollte er das in 40us +
> 10mV/us schaffen, bei 3.3V also in weniger als 400us.

Die 40us sind jedoch ein Delay, zählen also nicht zur 
Softstart-Rampe(nsteilheit).

: Bearbeitet durch User
von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was ist ein BOD? Die Google-Top-Treffer sind Books on Demand und 
Berufsverband der Orthoptistinnen. :-)

Das Problem ist, dass neben dem STM32 noch 6 weitere ICs und viele 
Kondensatoren am Vdd-Layer hängen. Entweder muss ich einen separaten 
Layer für den STM32 schaffen, oder alle Bauteile werden durch den BOD 
gebremst.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael M. schrieb:
> Würde ich auch so machen. Optimal wäre, wenn der Eingang
> Schmiittriger-Vehalten hätte. Dann reicht ein simples RC-Glied.

Ein STM32 hat nicht nur einen Versorgungspin, sondern ca. ein Dutzend. 
Ich kann mal im Datenblatt schauen, aber das müsste alle Versorgungspins 
betreffen.

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Was ist ein BOD? Die Google-Top-Treffer sind Books on Demand und
> Berufsverband der Orthoptistinnen.

https://startpage.com/sp/search?query=BOD+Microcontroller → zweiter 
Treffer (bei mir): https://www.mikrocontroller.net/articles/Brownout

von Gerd E. (robberknight)


Bewertung
1 lesenswert
nicht lesenswert
Ich würde erst mal den bisherigen Schaltplan sehen wollen bevor ich 
Lösungsvorschläge poste.

Es könnten z.B. zu wenig Kondensatoren an den Versorgungspins des STM32 
sein.

Oder eine größere Last, die vom STM32 geschaltet wird. Wenn die dann 
gleich beim Start des STM32 von der Firmware eingeschaltet wird, bricht 
die Spannung wieder unter das zum Starten notwendige Niveau. Das führt 
dann zum Schwingen.

von Michael M. (michaelm)


Bewertung
-2 lesenswert
nicht lesenswert
lars schrieb:
> Was ist ein BOD? Die Google-Top-Treffer sind Books on Demand und
> Berufsverband der Orthoptistinnen. :-)

So ist das, wenn Menschen bedenkenlos mit DEnglisch oder technisch 
seltenst gebräuchlichen Begriffen und Abkürzungen daherkommen und dann 
noch erwarten, dass jeder Leser es versteht.
Ich weiß es auch nicht, was es genau heißt bzw. bedeutet.

Nur der Kontext "im Resetmode" macht verständlich, was gemeint war.
Ich meine, es dürfte kein Problem sein, deinen Schnelldenker für wenige 
ms im Reset zu halten, bis das NT (=Netzteil) hochgefahren ist.
Das einzige, was noch paasieren könnte: Der (vielleicht relativ große) 
Einschaltstrom wird vom NT mit einem Spannungseinbruch quittiert. :-(
Dann hättest du schlechte Karten... ^^

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jack V. schrieb:
> https://startpage.com/sp/search?query=BOD+Microcontroller → zweiter
> Treffer (bei mir): https://www.mikrocontroller.net/articles/Brownout

Das klingt nicht schlecht.

Nach Lektüre des Datenblatts würde ich den Power Supply Supervisor des 
STM32s ausschalten und dann manuell der Reset halten, bis 3.3V erreicht 
sind. Dafür sind die BODs offenbar für gemacht.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Es könnten z.B. zu wenig Kondensatoren an den Versorgungspins des STM32
> sein.

Da sind 15x 100nF, 2x 2.2uF, 1x 1uF und 1x 4.7uF vorhanden. Bei VREF+ 
habe die ich Kondensatoren vergessen, aber das wird wohl nicht 
kriegsentscheidend sein.

> Oder eine größere Last, die vom STM32 geschaltet wird.

Nein, aber wie gesagt, befinden sich 6 unabhängige ICs auf dem Board 
(SDRAM, RS232-Transceiver, Überspannungsschutz, ESP, 2x Bustransceiver). 
Die und Kondensatoren werden den Knick erzeugen, von Einbruch sieht man 
beim Oszi nichts (siehe Anhang ganz oben).

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
lars schrieb:
> Wieso braucht der Regler so lange?

Schau mal wie lange die Netzspannung braucht, um von 0 Volt auf 320V 
anzusteigen: es sind 5ms.

Du kannst ein Netzteil verwenden, dass verzögert einschaltet, nachdem 
der Eingangskondensator gut geladen ist. Aber selbst dann ist ein 
allmähliches Ansteigen der Ausgangsspannung unvermeidbar, weil der 
Schaltwandler bei jedem Schaltvorgang nur ein begrenztes Päckchen 
Energie übertragen kann.

Jetzt weißt du, warum alle Mikrocontroller einen herausgeführten 
Reset-Pin haben.

Bei AVR Mikrocontrollern kann man die Startup-Zeit Verzögerung 
konfigurieren, zum Beispiel auf 65ms. Selbst das reicht nicht für jedes 
Netzteil aus.

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
-1 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Bei AVR Mikrocontrollern

lars schrieb:
> um u.a.  einen STM32 mit 3.3V zu versorgen.

???
Erkenne das Problem
wenns nicht 3,3V wäre würde ich ja den TL7705 vorschlagen, der war genau 
dafür gemacht, aber nur für 5V, ein TL7702 könnte passen wenn er 
angepasst wird und noch kaufbar ist.

: Bearbeitet durch User
von Achim S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Wieso braucht der Regler so lange?

Wie sieht der Spannungsverlauf am Eingang des TPS aus? Was hängt 
insgesamt als Last am Ausgang des TPS? Welche Ströme verlangst du im 
gemessenen Zeitbereich der Flanke von ihm?

lars schrieb:
> Nun startet der STM32 bei Anlegen der Versorgungsspannung von 5V in ca.
> 70% der Fälle nicht; ein manueller Reset (NRST auf LOW) funktioniert
> dann aber.

Wenn der STM32 startet, dann wird zunächst der HSI-Oszillator als CLK 
verwendet. Änderst du das in deinem Code? Schaltest du evtl. gleich zu 
Beginn auf eine andere Taktquelle um, bei der sich z.B. erst eine PLL 
einschwingen muss? Sowas könnte empfindlich auf einen weiteren Anstieg 
von VCC reagieren. Lass deinen STM testweise mal dauerhaft aus dem 
HSI-CLK laufen und schau, ob er sich weiter in 70% der Fälle aufhängt.

lars schrieb:
> Kann ich diesen Regler durch andere Größen bei Spule/Kondensatoren
> schneller machen?

ohne den tatsächlichen Schaltplan und Layout zu kennen, ist da schwer 
eine vernünftige Antwort zu geben.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> Erkenne das Problem

Habe ich. Wenn bei AVR 65ms einstellbar sind, dann zeigt das doch, dass 
dafür Bedarf besteht. Die 1ms sind schon sehr gut. Um das zu 
verdeutlichen, habe ich den AVR erwähnt.

Wenn der STM32 damit nicht alleine klar kommt, muss man ihm halt unter 
die Arme greifen.

von Oliver R. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie hast Du denn den NRST-Pin beschaltet. Laut den Datenblättern schlägt 
ST hier einen 100nF Kondensator vor, was zusammen mit einem Pullup von 
10k schon eine Zeitkonstante von 1ms ergibt, die der Reset verzögert 
wird. Den Kondensator könnte man testweise ja mal vergrössern.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> Wie sieht der Spannungsverlauf am Eingang des TPS aus? Was hängt
> insgesamt als Last am Ausgang des TPS? Welche Ströme verlangst du im
> gemessenen Zeitbereich der Flanke von ihm?

Das kann ich mal messen. Mit meinem Testprogramm ist die Last vermutlich 
nicht mehr als 300 mA + der inaktive ESP (also Strom, aber macht nix).

> Wenn der STM32 startet, dann wird zunächst der HSI-Oszillator als CLK
> verwendet. Änderst du das in deinem Code?

Nein, zu Testzwecken verwende ich HSI und LSI.

von lars (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ich habe übrigens etwas Interessantes im Datenblatt des STM32 gefunden:

    Vdd rise time rate: min. 20 us/V.

Also minimum(!), als Maximum steht da ∞. Dann müsste ihm die Steigung 
der Spannung doch eigentlich egal sein, oder?

Andererseits kann man beim Power Supply Supervisor des STM32 die zu 
erreichende Spannung einstellen. Vielleicht sollte ich einfach einen 
größeren Wert (als 1.8V) einstellen?

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Oliver R. schrieb:
> Wie hast Du denn den NRST-Pin beschaltet. Laut den Datenblättern schlägt
> ST hier einen 100nF Kondensator vor, was zusammen mit einem Pullup von
> 10k schon eine Zeitkonstante von 1ms ergibt, die der Reset verzögert
> wird.

Ernsthaft? Ich muss gestehen, ich habe nur einen Pull-up von 10K.

Weißt Du noch, wo das mit dem Kondensator steht?

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
lars schrieb:
> Vdd rise time rate: min. 20 us/V.
>
> Also minimum(!), als Maximum steht da ∞. Dann müsste ihm die Steigung
> der Spannung doch eigentlich egal sein, oder?

Wenn du den Reset Pin extern beschaltest, darf die Spannung langsamer 
ansteigen.

von Oliver R. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Es steht im Datenblatt unter "Recommended NRST pin protection". Ich habe 
es gerade beim STM32L452 geprüft, je nach verwendetem Typ kann es aber 
auch woanders stehen.

Ich würde einfach mal einen Kondensator von 470nF ausprobieren, das 
sollte den Reset um etwa 5ms verzögern und laut deinem Oszillogram ist 
die Betriebsspannung dann oben.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Wenn du den Reset Pin extern beschaltest, darf die Spannung langsamer
> ansteigen.

Würde Sinn ergeben, aber ich finde diese Einschränkung nicht:

Table 20. Operating conditions at power-up / power-down (regulator ON)
Subject to general operating conditions for T_A.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Oliver R. schrieb:
>> Wie hast Du denn den NRST-Pin beschaltet. Laut den Datenblättern schlägt
>> ST hier einen 100nF Kondensator vor, was zusammen mit einem Pullup von
>> 10k schon eine Zeitkonstante von 1ms ergibt, die der Reset verzögert
>> wird.
>
> Ernsthaft? Ich muss gestehen, ich habe nur einen Pull-up von 10K.
>
> Weißt Du noch, wo das mit dem Kondensator steht?

Du brauchst keinen externen Pullup verwenden, statt dessen den 
Kondensator.

Du hast bisher nicht geschrieben was für einen STM32 Du verwendest, ich 
verlinke daher mal das Datenblatt von irgendeinem:
https://www.st.com/resource/en/datasheet/stm32f072rb.pdf
Kapitel 6.3.15

Hab ich bisher bei allen STM32er-Modellen in dieser oder sehr ähnlicher 
Form gesehen.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
>     Vdd rise time rate: min. 20 us/V.
>
> Also minimum(!), als Maximum steht da ∞. Dann müsste ihm die Steigung
> der Spannung doch eigentlich egal sein, oder?

?

Was die Dir damit sagen wollen, ist daß die Spannung mindestens mit 20 
µs/V steigen muss, sie kann aber auch schneller steigen. Die Steigung 
der Spannung ist also nicht egal.

Wenn die Spannung bei Dir langsamer steigt, verletzt Du dieses 
Kriterium. Die Folge ist, daß der Controller manchmal nicht startet.

von Oliver R. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe allerdings die Erfahrung gemacht, dass der interne Pullup recht 
schwach ist, daher ist es kein Fehler einen etwas niederohmigeren 
externen Widerstand zu verwenden.

von M. K. (sylaina)


Bewertung
-2 lesenswert
nicht lesenswert
Michael M. schrieb:
> Nur der Kontext "im Resetmode" macht verständlich,

Eigentlich macht es der Kontext des Forum hier verständlich was 
wahrscheinlich damit gemeint war, im speziellen gar der Thread hier. Der 
Kontext des Post kommt als Bonus noch oben drauf ;)

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Oliver R. schrieb:
> Es steht im Datenblatt unter "Recommended NRST pin protection". Ich habe
> es gerade beim STM32L452 geprüft, je nach verwendetem Typ kann es aber
> auch woanders stehen.

Ach, da hinten in der kleinen Grafik! Ich muss gestehen, das habe ich 
überblättert. :-(

> Ich würde einfach mal einen Kondensator von 470nF ausprobieren, das
> sollte den Reset um etwa 5ms verzögern und laut deinem Oszillogram ist
> die Betriebsspannung dann oben.

Ja, das klingt super, vor allem weil das mit meinem aktuellen Board 
umsetzbar ist!

Ein anderen Wert für den Supervisor werde ich auch ausprobieren (wobei 
ich da ein Henne-Ei-Problem sehe).

Also vielen Dank bis hierher, ich melde mich später nochmal.

von lars (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Gerd E. schrieb:
>>     Vdd rise time rate: min. 20 us/V.
>
> Was die Dir damit sagen wollen, ist daß die Spannung mindestens mit 20
> µs/V steigen muss, sie kann aber auch schneller steigen. Die Steigung
> der Spannung ist also nicht egal.

Wenn da min. 20 us/V steht, interpretiere ich das so, dass auch 30 us/V 
oder 1 Tag/V in Ordnung wären.

Aber wahrscheinlich ist wirklich Deine Interpretation gemeint, dann ist 
nur Minimum in Verbindung mit der Einheit etwas missverständlich.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Du hast bisher nicht geschrieben was für einen STM32 Du verwendest.
> Hab ich bisher bei allen STM32er-Modellen in dieser oder sehr ähnlicher
> Form gesehen.

Eben, aber es handelt sich um einen STM32F746.

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Und dann wird z.b. die rise und Fall time beim beliebten 407 als 
mindestens 20 us/V angegeben. Maximum ist unendlich. D.h. bei diesem 
Prozessor darf die Spannung unendlich langsam steigen. Macht Sinn, der 
hat den bod bzw. Reset Voltage detector schon integriert und der 
funktioniert bestens solange man ihn nicht deaktiviert.

Vor der Lösung steht die Findung des Problems in diesem Fall...

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Gerd E. schrieb:
>>>     Vdd rise time rate: min. 20 us/V.
>>
>> Was die Dir damit sagen wollen, ist daß die Spannung mindestens mit 20
>> µs/V steigen muss, sie kann aber auch schneller steigen. Die Steigung
>> der Spannung ist also nicht egal.
>
> Wenn da min. 20 us/V steht, interpretiere ich das so, dass auch 30 us/V
> oder 1 Tag/V in Ordnung wären.
>
> Aber wahrscheinlich ist wirklich Deine Interpretation gemeint, dann ist
> nur Minimum in Verbindung mit der Einheit etwas missverständlich.

Ach so, aber bei Maximum steht ∞, und nicht 0. Spricht das nicht eher 
für meine Interpretation?

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karl schrieb:
> Und dann wird z.b. die rise und Fall time beim beliebten 407 als
> mindestens 20 us/V angegeben. Maximum ist unendlich. D.h. bei diesem
> Prozessor darf die Spannung unendlich langsam steigen. Macht Sinn, der
> hat den bod bzw. Reset Voltage detector schon integriert und der
> funktioniert bestens solange man ihn nicht deaktiviert.

Du warst schneller. :-)

> Vor der Lösung steht die Findung des Problems in diesem Fall...

Ja, vielleicht hilft der Kondensator, aber so genau ist mir das nicht 
klar.

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zu langsam getippt...

lars schrieb:
> Aber wahrscheinlich ist wirklich Deine Interpretation gemeint, dann ist
> nur Minimum in Verbindung mit der Einheit etwas missverständlich.

Denke ich nicht. Es ist jetzt weder bei schaltreglern noch bei load 
switches unüblich, dass die Anstiegszeit groß gemacht wird um die 
resultierenden Ströme einigermaßen in Zaum zu halten.

Genau dafür gibt es auch die interne resetbeschaltung, die statisch am 
Reset zupft solange der Controller nicht ausreichend versorgt ist.

Wie merkst du denn dass der Controller hängt? Und was macht der am 
Anfang nach dem Reset? Und hast du denn internen supervisor schon 
angemessen eingestellt?

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Ja, vielleicht hilft der Kondensator, aber so genau ist mir das nicht
> klar.

Der macht nichts besser als der intern generierte Reset. Sowas hat man 
zu 8051 Zeiten gemacht.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karl schrieb:
> Wie merkst du denn dass der Controller hängt? Und was macht der am
> Anfang nach dem Reset? Und hast du denn internen supervisor schon
> angemessen eingestellt?

Ich habe ein sehr einfaches Programm geschrieben, dass zwei LEDs 
abwechselnd blinken lässt.

Die Initialisierung der Peripherie habe ich auskommentiert. Mein main() 
sieht also so aus:

int main(void)
{
  HAL_Init();
  SystemClock_Config();
  MX_GPIO_Init();
  while (1) {
    LED1;   // LED 1 an (Makro für GPIOx->BSRR = ...;)
    LED20;  // LED 2 aus
    HAL_Delay(1000);
    LED10;  // LED 1 aus
    LED2;   // LED 2 an
    HAL_Delay(1000);
  }
}

Meistens passiert beim Anlegen der Spannung ... einfach gar nichts. Ich 
kann dann messen, dass Vdd auch 3.3V hat, aber die LEDs bleiben dunkel.

Manche GPIOs scheinen dann zumindest zeitweise auf Ausgang zu stehen, 
aber so genau kann ich das nicht prüfen.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karl schrieb:
> lars schrieb:
>> Ja, vielleicht hilft der Kondensator, aber so genau ist mir das nicht
>> klar.
>
> Der macht nichts besser als der intern generierte Reset. Sowas hat man
> zu 8051 Zeiten gemacht.

Die Idee ist, dass der externe Reset später kommt als der interne (den 
ich dann ausschalte).

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Die Idee ist, dass der externe Reset später kommt als der interne (den
> ich dann ausschalte).

Oder auch nicht, mal sehen.

von Oliver R. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Er sollte das mit dem externen Kondensator auf jeden Fall versuchen, da 
er ja schon ein Board hat und eine möglichst einfache Lösung sucht. Wenn 
die MCU jetzt schon in 70% der Fälle erfolgreich startet, ist das Thema 
damit u.U. erledigt. Dass es bessere Lösungsansätze gibt, steht ausser 
Frage.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Ich benutze zum ersten Mal einen Step-Down-Regulator (TPS62082 von TI),
> um u.a.  einen STM32 mit 3.3V zu versorgen.

Wieviel Strom zieht "u.a." und wie groß ist dein aufzuladender 
Ausgangskondensator?

> Was könnte ich jetzt dagegen tun?
Eine Möglichkeit wäre, ein Supervisor & Reset ICs zu verwenden, das 
verhindern, dass der µC los läuft, bevor eine ausreichende Versorgung 
zur Verfügung steht.
https://www.ti.com/de-de/power-management/supervisor-reset-ic/products.html

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Meistens passiert beim Anlegen der Spannung ... einfach gar nichts. Ich
> kann dann messen, dass Vdd auch 3.3V hat, aber die LEDs bleiben dunkel.
>
Debugger?
Mach dein Testprogramm Mal ohne hal mit dem internen Oszillator als 
Taktquelle. Keine pll, kein nichts. Kein hal delay, einfach for 
schleifen.
St hat in dem Gerümpel auch schon einiges verbockt was Mal ging. Wie ist 
deine taktkonfig? Und passt die zur hardware.?
> Manche GPIOs scheinen dann zumindest zeitweise auf Ausgang zu stehen,
> aber so genau kann ich das nicht prüfen.
Warum nicht? Oszi scheint vorhanden?
Eigene Platine? Selbst bestückt? Lötverbindungen über jeden Zweifel 
erhaben?

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Eine Möglichkeit wäre, ein Supervisor & Reset ICs zu verwenden

1990 hat angerufen. SCNR
Das hat der Controller alles drin.

von lars (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte noch etwas nachreichen:

Ich habe die Eingangsspannung in den Regler vermessen. Und zwar hat die 
Platine zwei mögliche Versorgungen: den Eingang eines 5V-Netzteils 
(erstes Bild, gemeinsame Masse war bei Messung etwas "off") sowie die 
5V-Spannungsversorgung eines alten Heimcomputer-Busses (zweites Bild). 
Man beachte die unterschiedlichen Skalen.

Das allererste Bild war die geregelte Spannung mit dem Bus, was auch der 
Hauptanwendungsfall ist.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Wieviel Strom zieht "u.a." und wie groß ist dein aufzuladender
> Ausgangskondensator?

Das kann ich nicht genau abschätzen. Die gesamte Schaltung kann ungefähr 
bis zu 1A ziehen, aber es ist ja im Testfall nicht alles aktiv. Der 
Ausgangskondensator ist (wie im TPS62082-Datenblatt vorgeschlagen) 22uF.

> Eine Möglichkeit wäre, ein Supervisor & Reset ICs zu verwenden

Abgesehen, dass das eingebaut ist, wurde bereits ein "BOD" für die 
Resetleitung vorgeschlagen, was praktikabel klingt -- wenn das die 
Ursache ist.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karl schrieb:
> Debugger?

Der Debugger funktioniert nicht, wenn die LEDs dunkel bleiben. Also 
Flashen funktioniert, der Breakpoint in main() wird auch gesetzt, aber 
er wird nicht erreicht. Ich denke, der STM32 läuft gar nicht.

> Mach dein Testprogramm Mal ohne hal mit dem internen Oszillator als
> Taktquelle.

Kann ich versuchen.

> St hat in dem Gerümpel auch schon einiges verbockt was Mal ging.

Also vorher habe ich einen F722 mit einem Linearregler verwendet, da 
hatte ich (auch am Bus, und ohne Reset-Kondensator) überhaupt keine 
Probleme. Deswegen bin ich auch ein wenig ratlos.

> Wie ist deine taktkonfig? Und passt die zur hardware.?

200 MHz, und manchmal läuft der STM32 ja auch los. Gerade mit der 
Netzspannung läuft er sogar ziemlich häufig los (oder es war Zufall).

>> Manche GPIOs scheinen dann zumindest zeitweise auf Ausgang zu stehen,
>> aber so genau kann ich das nicht prüfen.
> Warum nicht? Oszi scheint vorhanden?

Ja, aber wonach messe ich da, bzw. wie erkenne ich einen Ausgang? Bei 
einem Eingang floaten die Pins nicht notwendigerweise.

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Der Debugger funktioniert nicht, wenn die LEDs dunkel bleiben. Also
> Flashen funktioniert, der Breakpoint in main() wird auch gesetzt, aber
> er wird nicht erreicht. Ich denke, der STM32 läuft gar nicht.

Wenn Flashen geht, geht ziemlich sicher auch der Rest. Sicherheit 
bekommst du wenn der Breakpoint nicht in Main () liegt sondern im 
Startup Code aka Reset handler.

lars schrieb:
> 200 MHz, und manchmal läuft der STM32 ja auch los. Gerade mit der
> Netzspannung läuft er sogar ziemlich häufig los (oder es war Zufall).
Es kann ja sein, dass die Versorgung was damit zu tun hat, aber der 
Controller hat alle Mittel an Bord um eine funktionierende Hardware 
sicher ans Leben zu bekommen.
Datenblatt Kapitel 2.17 und alles was darin erwähnt wird bis zum 
bitteren Ende verfolgen.

Hat dein Gehäuse Den PDR_ON pin.? Korrekt beschaltet?

Quarz oder Oszillator? Takt geprüft? Schwingt der immer an?
Wenn hier was nicht passt traue ich dem St Hardware obfuscation layer 
alles zu.

Die Spannungen für bod und pvd lassen sich nichtflüchtig einstellen wenn 
ich mich korrekt erinnere. Setz die doch Mal auf z.b. 3 V.

lars schrieb:
> Ja, aber wonach messe ich da, bzw. wie erkenne ich einen Ausgang? Bei
> einem Eingang floaten die Pins nicht notwendigerweise.

Du hast das Thema aufgebracht ;-)

Als letzte Variante hat der tps einen pg Ausgang, der alles resetten 
kann bis die Spannung eingeregelt ist. Damit lernst du sicher am 
wenigsten.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karl schrieb:
> 1990 hat angerufen. SCNR
> Das hat der Controller alles drin.

Dann ist doch alles gut und er sollte bei richtiger Konfiguration sicher 
starten ;-)

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karl schrieb:
> Wenn Flashen geht, geht ziemlich sicher auch der Rest. Sicherheit
> bekommst du wenn der Breakpoint nicht in Main () liegt sondern im
> Startup Code aka Reset handler.

Er wird aber nur der BP in main() angezeigt. Single Step oder Continue 
haben auch keinen Effekt in der IDE.

> Hat dein Gehäuse Den PDR_ON pin.? Korrekt beschaltet?

Ja, liegt auf HIGH.

> Quarz oder Oszillator? Takt geprüft? Schwingt der immer an?
> Wenn hier was nicht passt traue ich dem St Hardware obfuscation layer
> alles zu.

Wie ich oben schon geschrieben habe, benutze ich für den Test HSI und 
LSI.

> Die Spannungen für bod und pvd lassen sich nichtflüchtig einstellen wenn
> ich mich korrekt erinnere. Setz die doch Mal auf z.b. 3 V.

Ja, das war ja auch eine Idee, den höher einzustellen. Wenn der 
nichtflüchtig ist, ist auch das Henne-Ei-Problem gelöst.

>> Ja, aber wonach messe ich da, bzw. wie erkenne ich einen Ausgang? Bei
>> einem Eingang floaten die Pins nicht notwendigerweise.
>
> Du hast das Thema aufgebracht ;-)

Nee, ich habe gesagt, ich vermute es, dann hast Du auf das Oszi 
verwiesen. :-)

> Als letzte Variante hat der tps einen pg Ausgang, der alles resetten
> kann bis die Spannung eingeregelt ist. Damit lernst du sicher am
> wenigsten.

Hmm, soweit ich weiß, zeigt der nur den Zustand an. Oder willst Du ihn 
mit EN verbinden? Jedenfalls ist PG im Moment nicht verbunden.

von Achim S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Das allererste Bild war die geregelte Spannung mit dem Bus, was auch der
> Hauptanwendungsfall ist.

wenn du jetzt mit zwei Kanälen gleichzeitig messen würdest, könnte man 
wahrscheinlich direkt sehen, dass der langsame Spannungsanstieg am 
Ausgang des TPS dem langsamen Spannungsanstieg am Eingag des TPS folgt. 
Das wäre dann die Antwort auf deine ursprüngliche Frage, warum der TPS 
so langsam ist.

Da du ja die zweite Variante der Versorgung hast, bei der die Spannung 
sehr viel schneller ansteigt: hängt sich der STM mit der Variante 
ebenfalls in 70% der Fälle auf? Und wie sieht dabei die Flanke der 
VDD-Versorgung aus? Wenn man das zusammen nimmt kann man mit etwas Glück 
eindeutig entscheiden, ob der langsame Spannungsanstieg wirklich die 
Ursache für dein Problem ist oder nicht.

lars schrieb:
> Wie ich oben schon geschrieben habe, benutze ich für den Test HSI und
> LSI.

In deinem Code steht halt nur folgender Aufruf, ohne den Inhalt der 
Routinen zu zeigen:

  HAL_Init();
  SystemClock_Config();
  MX_GPIO_Init();

Wenn ich nur diese Code-Sequenz sehe, dann ist SystemClock_Config() halt 
die naheliegendste Stelle, wo sich was aufhängen kann.

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Dann ist doch alles gut und er sollte bei richtiger Konfiguration sicher
> starten ;-)

Ja das sollte er wohl.

lars schrieb:
> Er wird aber nur der BP in main() angezeigt. Single Step oder Continue
> haben auch keinen Effekt in der IDE.

Dann ist es Zeit die Grenzen der ide zu verlassen.

lars schrieb:
> Wie ich oben schon geschrieben habe, benutze ich für den Test HSI und
> LSI.

Sorry hab ich wohl überlesen.

lars schrieb:
> Ja, das war ja auch eine Idee, den höher einzustellen. Wenn der
> nichtflüchtig ist, ist auch das Henne-Ei-Problem gelöst.

Ja genau. Wenn du den hohen Takt der pll nutzt geht das afair nur mit 
den höheren Spannungen oder irgendwas an den flash waitstates muss 
angepasst werden. Soll heißen, sobald du Features nutzt die nicht im 
gesamten Spannungsbereich zuverlässig funktionieren, muss der bod o.ä. 
entsprechend konfiguriert werden. Bequemerweise bringt der Controller 
alles mit, so dass eigentlich keine externen firlefänze nötig sind.

lars schrieb:
> Nee, ich habe gesagt, ich vermute es, dann hast Du auf das Oszi
> verwiesen. :-)
Nur weil du sagtest du könntest das nicht prüfen. Egal.

lars schrieb:
> Hmm, soweit ich weiß, zeigt der nur den Zustand an. Oder willst Du ihn
> mit EN verbinden? Jedenfalls ist PG im Moment nicht verbunden.

Der sollte anzeigen dass die Ausgangsspannung des Reglers in der Nähe 
der Sollspannung ist und kann für power-sequencing oder eben den Reset 
von anderen Komponenten Sorgen. Wenn du nicht den bod des Controllers 
nutzen möchtest oder kannst, kann man damit z.b. alle resets im System 
auf Low halten bis die Spannung da ist.

von Irgend W. (Firma: egal) (irgendwer)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Ja, das war ja auch eine Idee, den höher einzustellen. Wenn der
> nichtflüchtig ist, ist auch das Henne-Ei-Problem gelöst.

Schau dir mal diese beiden Kapitel an (ST verteilt die Infos gerne auf 
mehrere Dokumente:-):
RM0385 Kap.4.2.2 Brownout reset (BOR)
und
DS10916 Table 22
Dort findest du was zu "Brownout threshold level 1 bis 3 - VBOR1-3) mit 
den verschiedenen Spannungen.

https://www.st.com/resource/en/reference_manual/dm00124865-stm32f75xxx-and-stm32f74xxx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf
https://www.st.com/resource/en/datasheet/stm32f746ng.pdf

von lars (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Also, ich versuche erst mal den BOR-Level zu setzen. Dazu findet man das 
entsprechende Register FLASH_OPTCR an Adresse 0x1fff 0000 (Bild 1).

Wenn man sich aber das Skript von Segger (J-Link) ansieht, findet man 
dort (u.a.)
1
w1 0x40023C15 0xBB  // Set ROP to Level 1. 0xAA = Level 0; 0xCC = Level 2
2
w1 0x40023C14 0xFE  // Set OPTSTRT bit.

Hier findet sich also eine andere Adresse, die laut Memory Map zu AHB1 
gehört. Laut Referenz befindet sich dort aber auch FLASH_OPTCR (Bild 2). 
Das sieht mir aber nicht nach Bit Banding aus.

Bei beiden Adressen befindet sich der relevante 2-Bit-Wert an der Stelle 
0xc. Wieso wird dann 0xaa, 0xbb oder 0xcc geschrieben?

Und wieso sind die Adressen falsch rum? Soll das Little Endian sein? 
Aber welche Adressen haben dann die Bits 16-31 vom Wort?

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
>
1
> w1 0x40023C15 0xBB  // Set ROP to Level 1. 0xAA = Level 0; 0xCC = Level 
2
> 2
3
> w1 0x40023C14 0xFE  // Set OPTSTRT bit.
4
>

Nach nochmaligem Lesen geht es bei dem Skript nicht um BOR, sondern um 
eine andere Funktion. Das heißt, ich muss bloß die Werte anpassen.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Noch ein Update -- Mein J-Link command file sieht jetzt so aus:
1
device stm32f746ie
2
if 1
3
speed 1000
4
con
5
sleep 100
6
w4 0x40023C08 0x08192A3B // Clear option lock 
7
w4 0x40023C08 0x4C5D6E7F
8
sleep 100
9
w1 0x40023C14 0xF5       // Set BOR (flash option control register)
10
sleep 200
11
mem32 0x1fff0000 1        // read back (Flash option byte)
12
sleep 200
13
r                        // reset
14
sleep 10000
15
q

Allerdings gibt die Leseoperation (mem32) immer den unveränderten Wert 
aus, auch bei mehrmaligem Flashen.

Kennst jemand den Unterschied zwischen Option Control Register und 
Option Byte? Welches muss ich schreiben?

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Keine Ahnung. Für stm32 nahm ich immer das stlink utility. Da konnte man 
das einfach anklicken.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jetzt hat es geklappt -- ich musste das Setzen des Wertes auf zwei 
Anweisungen aufteilen, da ein Bit nach dem Wert gesetzt werden muss.
1
device stm32f746ie
2
if 1
3
speed 1000
4
con
5
sleep 100
6
w4 0x40023C08 0x08192A3B // Clear option lock 
7
w4 0x40023C08 0x4C5D6E7F
8
sleep 100
9
w1 0x40023C14 0xF0       // Set BOD bit.
10
sleep 100
11
w1 0x40023C14 0xF2       // Set OPTSTRT bit.
12
sleep 200
13
mem32 0x1fff0000 1
14
sleep 200
15
r
16
sleep 10000
17
q

Damit ist dann 0x1FFF0000 = 550CAAF3, das ist der höchste BOD-Level.

Leider funktioniert das Starten genauso schlecht wie bisher. Ich werde 
daher jetzt den Kondensator am Reset ausprobieren.

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Leider funktioniert das Starten genauso schlecht wie bisher. Ich werde
> daher jetzt den Kondensator am Reset ausprobieren.

Schade, das heißt aber nur, dass etwas anderes nicht stimmt. Der einzige 
Grund, einen externen Reset zu verwenden ist, wenn man eine 
Resetspannung verwenden möchte die der interne Resetgenerator nicht 
kann.

Wenn du "nur" zum Ziel kommen willst, bastel was externes dran. Wenn es 
das nächste Mal auch gehen soll, Versuche die Ursache zu verstehen.

Viel Erfolg in jedem Fall!
(Und bitte Nachsicht bezüglich der 8051er Kommentare, nicht böse 
gemeint)

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Karl schrieb:
> Der einzige
> Grund, einen externen Reset zu verwenden ist, wenn man eine
> Resetspannung verwenden möchte die der interne Resetgenerator nicht
> kann.

Oder wenn man ein anderes Timing braucht.

Ich habe Steckernetzteil, das kommt zügig auf 5V, sackt dann wieder auf 
1V ab und geht dann wieder auf 5V hoch. Ohne externen Reset-Kondensator 
komme ich damit nicht weit.

> Versuche die Ursache zu verstehen.

Guter Vorschlag.

: Bearbeitet durch User
von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karl schrieb:
> Schade, das heißt aber nur, dass etwas anderes nicht stimmt.

Heute morgen ist mir eingefallen, dass der Power Supervisor noch aktiv 
ist. Vielleicht habe ich bessere Resultate, wenn ich den (über PDR_ON) 
ausschalte.

> Wenn es das nächste Mal auch gehen soll, Versuche die Ursache zu verstehen.

Ja, aber das ist leichter gesagt, als getan. Leider kann man in den 
STM32 nicht hineinschauen, also weiß man nicht, wann genau er den Reset 
wegnimmt.

Oder es ist eine ganz andere Ursache, aber wie will man das feststellen, 
wenn er nicht startet? In diesem Fall ist der STM32 nur ein totes 
Bauteil.

Immerhin will ich noch zwei Tests machen, aber auch die drehen sich um 
die Spannung.

> (Und bitte Nachsicht bezüglich der 8051er Kommentare, nicht böse
> gemeint)

Kein Problem!

von Achim S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Oder es ist eine ganz andere Ursache, aber wie will man das feststellen,
> wenn er nicht startet?

Oben habe ich dir einen Vorschlag dazu gemacht. Wenn du den durchführst 
sollte sich mit einiger Wahrscheinlichkeit zumindest klären lassen, ob 
die Dauer der Vdd-Flanke entscheidend für das Startup-Verhalten ist oder 
nicht.

Achim S. schrieb:
> wenn du jetzt mit zwei Kanälen gleichzeitig messen würdest, könnte man
> wahrscheinlich direkt sehen, dass der langsame Spannungsanstieg am
> Ausgang des TPS dem langsamen Spannungsanstieg am Eingag des TPS folgt.
> Das wäre dann die Antwort auf deine ursprüngliche Frage, warum der TPS
> so langsam ist.
>
> Da du ja die zweite Variante der Versorgung hast, bei der die Spannung
> sehr viel schneller ansteigt: hängt sich der STM mit der Variante
> ebenfalls in 70% der Fälle auf? Und wie sieht dabei die Flanke der
> VDD-Versorgung aus? Wenn man das zusammen nimmt kann man mit etwas Glück
> eindeutig entscheiden, ob der langsame Spannungsanstieg wirklich die
> Ursache für dein Problem ist oder nicht.

von lars (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
>> wenn du jetzt mit zwei Kanälen gleichzeitig messen würdest, könnte man
>> wahrscheinlich direkt sehen, dass der langsame Spannungsanstieg am
>> Ausgang des TPS dem langsamen Spannungsanstieg am Eingag des TPS folgt.

Ja, das war einer der Tests, den ich machen wollte. Das Ergebnis ist 
angehängt.

Im ersten Bild sieht man (von oben nach unten) Vin (5V, am Bus), ein 
STM32 GPIO-Ausgang mit HIGH, und Vout (3.3V, Regler Ausgang). Bei dieser 
Messung startete der STM32 nicht.

Wie man sieht, wird der Ausgang nicht auf HIGH geschaltet, wie in CubeMX 
konfiguriert, was darauf hindeutet, dass der STM32 nicht startet (oder 
an der falschen Adresse?). Oder hat die kleine Spitze etwas zu bedeuten?

Der TPS62082 scheint ab ca. 1.6V zu arbeiten, obwohl seine 
Mindestspannung 2.3V beträgt?!

Der Knick in Vout wurde ja schon mit den anderen Komponenten erklärt, 
die ab dann aktiv werden.

Ich weiß nicht recht, wie ich das jetzt interpretieren soll. Man sieht 
ja leider nicht, ab welcher Spannung der STM32 seinen internen Reset 
abschaltet. Oder gibt die Spitze einen Hinweis?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Man sieht ja leider nicht, ab welcher Spannung der STM32
> seinen internen Reset abschaltet.

Der Reset-Pin ist doch nicht nur ein Eingang sondern auch ein Ausgang. 
Kann man da nicht einfach messen, wann er auf High geht?

von lars (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Der Reset-Pin ist doch nicht nur ein Eingang sondern auch ein Ausgang.
> Kann man da nicht einfach messen, wann er auf High geht?

Also ich hätte vermutet, dass bspw. der Brown Out Reset nicht 
physikalisch den Reset-Pin schaltet, sondern intern irgendwie Stop sagt.

Aber nichtsdestotrotz gibt es da eine Bewegung (s. Bild). Ich habe den 
J-Link entfernt (da er auch am Reset-Pin hängt). Jetzt bleibt nur noch 
der 10K-Pullup und der interne Pullup. Offenbar schaltet BOR etc. doch 
den Pin!

Eigentlich sollte der STM32 ab 1.8V starten, aber ich habe das Level ja 
auf 3.xV hoch gesetzt.

Nur: Was lernen wir jetzt daraus?

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Also ich hätte vermutet, dass bspw. der Brown Out Reset nicht
> physikalisch den Reset-Pin schaltet, sondern intern irgendwie Stop sagt.

Datenblatt und reference Manual lesen.

lars schrieb:
> Nur: Was lernen wir jetzt daraus?

Dein Problem liegt nicht am Reset und der langsamen Spannung. (Puh, 8051 
;-))

Wie war das nochmal mit dem Debugger wenn der Controller nicht startet? 
Geht der? Verbindung aufnehmen, halten und schauen was der Prozessor so 
macht. Also ohne Reset und ohne breakpoint.
Ungehandelter Interrupt oder so? Im Zweifel an jeder zweiten Codezeile 
einen Pin toggeln lassen um zu sehen wie weit er kommt. Wie gesagt, 
Minimalbeispiel ohne schnellen Takt etc.

von Achim S. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Der TPS62082 scheint ab ca. 1.6V zu arbeiten, obwohl seine
> Mindestspannung 2.3V beträgt?!

Bei 2,3V arbeitet er garantiert. Aber offenbar versucht er es ausch 
schon vorher.

lars schrieb:
> Der Knick in Vout wurde ja schon mit den anderen Komponenten erklärt,
> die ab dann aktiv werden.

Das war die erste und naheliegenste Erklärung. Aber seit du den 
Spannungsanstieg am TPS-Eingang gemessen hast ist klar, dass die echte 
Erklärung eine andere ist.

Deine 5V BUS laufen sehr langsam hoch. Sobald sie 1,6V erreicht haben 
schaltet der TPS ein und regelt seine Ausgangsspannung bis zur momentan 
verfügbaren Eingangsspannung hoch. So kommt er mit der schnellen 
Steigung auf ca. 2V. Mehr als diese 2V kann er am Ausgang nicht liefern, 
weil sein Eingang noch nicht höher ist. Deswegen läuft der TPS-Ausgang 
von da an mit der reduzierten Geschwindigkeit nach oben, die durch die 
5V-Bus vorgegeben sind. Im Anhang habe ich die beiden Kurven mal 
übereinander geschoben, um den Zusammenhang zu verdeutlichen. Sobald 
5V-Bus dann über 3,3V geht, beginnt der TPS zu regeln und hält die 3,3V 
fest.

Der Knick und die geringe Geschwindigkeit am TPS-Ausgang kommt also 
einfach daher, dass die Spannung am TPS-Eingang so langsam ansteigt. 
Nicht der TPS ist zu langsam, sondern die 5V-Bus.

lars schrieb:
> Nur: Was lernen wir jetzt daraus?

Wir lernen etwas daraus, wenn du dein Experiment nicht mit der 
Versorgung aus 5V-Bus sondern mit der aus 5V Netzteil wiederholst. Deren 
Anstiegsgeschwindigkeit ist viel schneller, wie du hier gezeigt hast:
https://www.mikrocontroller.net/attachment/485348/DS0001.PNG

Wenn du damit nochmal misst würde ich erwarten, dass der TPS nicht mehr 
durch sein Eingangssignal ausgebremst wird, sondern eine schnelle Flanke 
ohne Knick am Ausgang abliefert. Miss bitte nochmal nach, ob diese 
Erwartung stimmt.

Und dann ist die Frage: hängt sich der STM bei dieser schnellen VDD 
Flanke ohne Knick immer noch in 70% der Fälle auf oder nicht. Wenn er 
sich immer noch aufhängt, weißt du, dass das nichst mit der VDD-Flanke 
zu tun hat. Wenn er sich nicht mehr aufhängt weißt du, dass die langsame 
Flanke oder der Knick darin fürs Aufhängen verantwortlich sind.

Zu Beginn hattest du geschrieben, dass du mit LDO diese Probleme nicht 
hattest. Der LDO hat bei Versorgung mit 5V-Bus sicher keine schnellere 
Flanke als der TPS (denn auch der LDO kann die Spannung nicht schneller 
hochlaufen lassen als die 5V-Bus an seinem Eingang). Wenn der Aufbau mit 
LDO also aus 5V-Bus funktioniert weißt du als nächstes, dass nicht die 
absolute Dauer der Flanke verantwortlich ist (der Knick in der Flanke 
kann es aber weiterhin sein, denn der LDO-Ausgang wird wahrscheinlich 
keinen solchen Knick liefern).

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> hängt sich der STM bei dieser schnellen VDD Flanke ohne Knick immer noch
> in 70% der Fälle auf oder nicht.

Das war glaube ich so.
Zu tps vs ldo: auch hier kommt es auf die konkreten Modelle an. Manche 
haben einen soft Start, Manche nicht so Recht. Außerdem unterscheiden 
sich vermutlich die vorhandenen Kapazitäten ganz enorm zwischen 
schaltregler und ldo. Ein alter Computer der an den 5v auf einmal z.b. 
47uF Keramik aufladen soll kann schon Mal ins schwitzen kommen.

Ich sehe nach wie vor keinen Grund warum der Controller nicht anlaufen 
sollte. Was hängt noch an Peripherie dran? Natürlich bräuchte man dazu 
einen Schaltplan, den ich aber vielleicht nicht ausreichend studieren 
möchte.

von Achim S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karl schrieb:
> Ich sehe nach wie vor keinen Grund warum der Controller nicht anlaufen
> sollte.

da bin ich bei dir - eigentlich müsste das Teil laufen. Außer im 
Startup-Code versteckt sich irgendwas sehr heikles, das wir bisher nicht 
sehen und das die Probleme erklärt.

Aber nichtsdestotrotz hängt er sich eben meist auf. Und um zu klären, ob 
es wirklich etwas mit der Spannungsrampe zu tun hat oder nicht, fände 
ich die vorgeschlagenen Untersuchungen sinnvoll.

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> fände ich die vorgeschlagenen Untersuchungen sinnvoll.

Full ACK

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Beobachte die Versorgungsspannung mal über einen längeren Zeitraum, z.B. 
10 Sekunden.

Es wäre doch denkbar, dass sie später nochmal einbricht - warum auch 
immer.

von Oliver R. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mal was ganz anderes: den BOOT0 Pin hast du auf GND Potential gelegt? 
Falls der floatet, landet der STM gerne ab und zu im Bootloader.

von lars (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Erstmal einen Zwischenbericht:

1) BOOT0. Liegt auf Vss, war tatsächlich erst auf Vdd, aber das habe ich 
als erstes behoben.

2) Fault Handler. Ich habe in alle Handler eingebaut, dass beide LEDs 
leuchten. Aber beim Tippen wird mir klar, dass das Banane ist, denn GPIO 
ist wahrscheinlich noch gar nicht initialisiert. Ich muss mir also etwas 
anderes überlegen, was ohne Debugger geht.

3) Debugger. Ich habe das Debug-Skript auf
1
set host-charset CP1252
2
set target-charset CP1252
3
monitor speed 30
4
monitor endian little
5
monitor speed auto
6
set remote memory-write-packet-size 1024

verkürzt (da ließe sich sicher noch entrümpeln), und damit habe ich den 
angehängten Zustand erreicht. Die Adressen liegen in "Reserved", sagen 
mir aber nichts.

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also was den Debugger angeht: Zustand herstellen, verbinden ohne Reset, 
Register auslesen. Insbesondere PC, LR, sp. Dazu braucht es keine Ide. 
Jlink command Tool (hab vergessen wie es heißt) oder openocd reichen.

von lars (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal den Spannungsverlauf bei meiner alten Platine mit einem LDO 
NCP-1113(?), die Skala ist etwas größer.

von lars (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Beobachte die Versorgungsspannung mal über einen längeren Zeitraum, z.B.
> 10 Sekunden.
>
> Es wäre doch denkbar, dass sie später nochmal einbricht - warum auch
> immer.

Sieht nicht so aus.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Ich würde erst mal den bisherigen Schaltplan sehen wollen bevor ich
> Lösungsvorschläge poste.
Achim S. schrieb:
> ohne den tatsächlichen Schaltplan und Layout zu kennen, ist da schwer
> eine vernünftige Antwort zu geben.
Karl schrieb:
> Natürlich bräuchte man dazu einen Schaltplan
Das sehe ich auch so. Am Besten vom Versorgungseingang bis hin zum µC, 
der da nicht anläuft. Sooooo unglaublich geheim wird der ja schon nicht 
sein.

lars schrieb:
> um u.a.  einen STM32 mit 3.3V zu versorgen.
Ist das, was du da vor dir hast, eine Neuentwicklung?
Oder testest du den Schaltregler mit einem fertigen ST-Evalboard?
Falls das eine Eigenentwicklung ist: wie sieht das Layout aus?

lars schrieb:
> Gerd E. schrieb:
>> Es könnten z.B. zu wenig Kondensatoren an den Versorgungspins des STM32
>> sein.
> Da sind 15x 100nF, 2x 2.2uF, 1x 1uF und 1x 4.7uF vorhanden.
Im Datenblatt auf Seite 95 Bild 22 ist von 22 Stk. 100n Kondensatoren 
die Rede. Und dann ist da noch Text, der auch beachtet werden will und 
andeutet, dass man an Kondensatoren nicht sparen sollte, weil sich das 
Device sonst "incorrect" verhalten könnte.

von lars (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> Deine 5V BUS laufen sehr langsam hoch. [...]
> Mehr als diese 2V kann er am Ausgang nicht liefern,
> weil sein Eingang noch nicht höher ist. Deswegen läuft der TPS-Ausgang
> von da an mit der reduzierten Geschwindigkeit nach oben [...]
> Im Anhang habe ich die beiden Kurven mal
> übereinander geschoben, um den Zusammenhang zu verdeutlichen.

Super, vielen Dank, da sieht man es perfekt -- Du hast natürlich recht.

> Wir lernen etwas daraus, wenn du dein Experiment nicht mit der
> Versorgung aus 5V-Bus sondern mit der aus 5V Netzteil wiederholst.

Ja, ist angehängt. Das war gar nicht so einfach, denn wenn der Jack den 
Mittel-Pin nur kurz berührt, hat man einen Spike, und sonst 0V.

> ohne Knick

Richtig!

> Und dann ist die Frage: hängt sich der STM bei dieser schnellen VDD
> Flanke ohne Knick immer noch in 70% der Fälle auf oder nicht.

Nein, die Erfolgsquote ist viel höher, aber sie ist nicht 100%! Wobei 
die Fehlfunktionen vielleicht auch durch "falsches Einstecken" 
verursacht werden (s.o.).

> Wenn er
> sich immer noch aufhängt, weißt du, dass das nichst mit der VDD-Flanke
> zu tun hat. Wenn er sich nicht mehr aufhängt weißt du, dass die langsame
> Flanke oder der Knick darin fürs Aufhängen verantwortlich sind.

Tja, offenbar hat es schon damit zu tun. Also meine Wette wäre auf der 
Spannung.

> Zu Beginn hattest du geschrieben, dass du mit LDO diese Probleme nicht
> hattest.

Ja, siehe Oszi-Screenshot weiter oben.

von lars (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
>> Ich würde erst mal den bisherigen Schaltplan sehen wollen bevor ich
>> Lösungsvorschläge poste.

Angehängt. Ganz rechts sind die System-Pins vom STM32F746.

> Ist das, was du da vor dir hast, eine Neuentwicklung?

Ja, wobei die Vorgängerversion (mit LDO) funktioniert hat.

>> Da sind 15x 100nF, 2x 2.2uF, 1x 1uF und 1x 4.7uF vorhanden.
> Im Datenblatt auf Seite 95 Bild 22 ist von 22 Stk. 100n Kondensatoren
> die Rede.

Ja, ich habe die von VREF+ und NRST vergessen, und vielleicht auch 
verzählt. Es gibt kein Versorgungs-Vdd, was keinen Kondensator hat.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
>> Wenn er
>> sich immer noch aufhängt, weißt du, dass das nichst mit der VDD-Flanke
>> zu tun hat. Wenn er sich nicht mehr aufhängt weißt du, dass die langsame
>> Flanke oder der Knick darin fürs Aufhängen verantwortlich sind.
>
> Tja, offenbar hat es schon damit zu tun. Also meine Wette wäre auf der
> Spannung.

Ach so, aber wieso spielt der Knick eine Rolle, wenn der STM32 die ganze 
Zeit im Resetzustand ist?

von Achim S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Ich habe mal den Spannungsverlauf bei meiner alten Platine mit einem LDO
> NCP-1113(?), die Skala ist etwas größer.

Und damit bootet es zuverlässig, richtig? Dann haben deine Probleme 
zumindest mal sicher nichts mit einer langen Dauer der Vdd-Flanke zu 
tun. Den die gesamte Flankendauer ist hier nicht geringer als die 
Flankendauer beim TPS. (Mit dem Knick in der Flanke könnten die Probleme 
natürlich immer noch zusammen hängen)

lars schrieb:
> Nein, die Erfolgsquote ist viel höher, aber sie ist nicht 100%! Wobei
> die Fehlfunktionen vielleicht auch durch "falsches Einstecken"
> verursacht werden (s.o.).

Was meinst du mit falschem Einstecken? Stellst du den Kontakt her, indem 
du eine Steckverbindung schließt? Das kann alle möglichen Faxen machen 
(die auf dem Oszibild weit vor oder weit nach dem beobachteten 
Zeitfenster liegen).

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
lars schrieb:
> Es gibt kein Versorgungs-Vdd, was keinen Kondensator hat.
Das gibt mir zu denken...
Im dortigen Fließtext steht ausdrücklich, dass "each power supply 
/pair/" einen Kondensator haben soll. Damit ist gemeint, dass der 
Kondensator mit einem Pad am µC-Vss-Pin und mit dem anderen Pad am 
µC-Vdd-Pin angeschlossen ist, und dann die Durchkontaktierung nach GND 
und Vdd erfolgt.

Such dazu mal nach ap1609111_xc164cs_pcb.pdf und sieh dir den Abschnitt 
2.4 an.

Wir hatten dazu auch mal im Beitrag "STM32 - 2 lagig Routen, wohin mit VDD und VSS" 
was diskutiert.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Das gibt mir zu denken...
> Im dortigen Fließtext steht ausdrücklich, dass "each power supply
> /pair/" einen Kondensator haben soll. Damit ist gemeint, dass der
> Kondensator mit einem Pad am µC-Vss-Pin und mit dem anderen Pad am
> µC-Vdd-Pin angeschlossen ist, und dann die Durchkontaktierung nach GND
> und Vdd erfolgt.

Ist ja gut, die Paare sind da eingeschlossen -- aber es gibt Vdd, die 
kein Vss haben.

von lars (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Karl schrieb:
> Also was den Debugger angeht: Zustand herstellen, verbinden ohne Reset,
> Register auslesen. Insbesondere PC, LR, sp. Dazu braucht es keine Ide.
> Jlink command Tool (hab vergessen wie es heißt) oder openocd reichen.

Das ist der JLink Commander. Den habe ich gerade ausprobiert, und 
folgendes herausgefunden.

Beim Verbinden lief die MCU, also habe ich sie erst mal gestoppt. Dabei 
wurden automatisch die Register angezeigt:
1
J-Link>halt
2
PC = 1FF01752, CycleCnt = 13E4E3F9
3
R0 = 40004800, R1 = 40003000, R2 = 0000AAAA, R3 = 006210DF
4
R4 = 00000000, R5 = 0000AAAA, R6 = 40003000, R7 = 00000000
5
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
6
R12= 00800100
7
SP(R13)= 20003AF8, MSP= 20003AF8, PSP= 00000000, R14(LR) = 1FF0160F
8
XPSR = 21000000: APSR = nzCvq, EPSR = 01000000, IPSR = 000 (NoException)
9
CFBP = 00000001, CONTROL = 00, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 01
10
11
FPS0 = 00000000, FPS1 = 00000000, FPS2 = 00000000, FPS3 = 00000000
12
FPS4 = 00000000, FPS5 = 00000000, FPS6 = 00000000, FPS7 = 00000000
13
FPS8 = 00000000, FPS9 = 00000000, FPS10= 00000000, FPS11= 00000000
14
FPS12= 00000000, FPS13= 00000000, FPS14= 00000000, FPS15= FFFFFFFF
15
FPS16= 00000000, FPS17= 00000000, FPS18= 00000000, FPS19= 00000000
16
FPS20= 00000000, FPS21= 00000000, FPS22= 00000000, FPS23= 00000000
17
FPS24= 00000000, FPS25= 00000000, FPS26= 00000000, FPS27= 00000000
18
FPS28= 00000000, FPS29= 00000000, FPS30= 00000000, FPS31= FFFFFFFF
19
FPSCR= 00000000

Dann habe ich einen Reset gemacht und nochmal die Register angezeigt:
1
J-Link>r
2
Reset delay: 0 ms
3
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
4
Reset: Halt core after reset via DEMCR.VC_CORERESET.
5
Reset: Reset device via AIRCR.SYSRESETREQ.
6
J-Link>regs
7
PC = 002106C4, CycleCnt = 00000000
8
R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000
9
R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000
10
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
11
R12= 00000000
12
SP(R13)= 20010000, MSP= 20010000, PSP= 00000000, R14(LR) = FFFFFFFF
13
XPSR = 01000000: APSR = nzcvq, EPSR = 01000000, IPSR = 000 (NoException)
14
CFBP = 00000000, CONTROL = 00, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 00
15
16
FPS0 = 00000000, FPS1 = 00000000, FPS2 = 00000000, FPS3 = 00000000
17
FPS4 = 00000000, FPS5 = 00000000, FPS6 = 00000000, FPS7 = 00000000
18
FPS8 = 00000000, FPS9 = 00000000, FPS10= 00000000, FPS11= 00000000
19
FPS12= 00000000, FPS13= 00000000, FPS14= 00000000, FPS15= FFFFFFFF
20
FPS16= 00000000, FPS17= 00000000, FPS18= 00000000, FPS19= 00000000
21
FPS20= 00000000, FPS21= 00000000, FPS22= 00000000, FPS23= 00000000
22
FPS24= 00000000, FPS25= 00000000, FPS26= 00000000, FPS27= 00000000
23
FPS28= 00000000, FPS29= 00000000, FPS30= 00000000, FPS31= FFFFFFFF
24
FPSCR= 00000000

In der Map-Datei habe ich zu dieser Adresse den Startup-Code gefunden:
1
002106c4 <Reset_Handler>:
2
3
    .section  .text.Reset_Handler
4
  .weak  Reset_Handler
5
  .type  Reset_Handler, %function
6
Reset_Handler:  
7
  ldr   sp, =_estack      /* set stack pointer */
8
  2106c4:       f8df d034       ldr.w   sp, [pc, #52]   ; 2106fc <LoopFillZerobss+0x14>
9
10
/* Copy the data segment initializers from flash to SRAM */  
11
  movs  r1, #0
12
  2106c8:       2100            movs    r1, #0
13
  b  LoopCopyDataInit
14
  2106ca:       e003            b.n     2106d4 <LoopCopyDataInit>

Also eigentlich so, wie es sein sollte, insb. PC und SP. Wieso am Ende 
die Adresse 0x1ff0xxxx herauskommt, weiß ich nicht.

Ich habe die ganze Map-Datei mal angehängt.

Der Commander erlaubt auch Single Stepping; mal sehen, ob ich etwas 
herausfinde.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: Wenn der STM32 startet, oder wenn ich im Commander einen Reset 
auslöse, erreiche ich mit Single Stepping ganz normal main(), und der PC 
bleibt auch in der main()-Schleife.

Wenn der STM32 aber nicht startet und ich verbinde mich, dann habe ich 
diese seltsame Adresse wie im ersten Beispiel gezeigt als PC. Die 
Adresse ist im Reserved Speicherbereich, und offenbar führt die MCU dort 
zufällige Befehle in einer kurzen Schleife aus. Beliebiges Beispiel:
1
1FF01752:  9B 06              LSLS      R3, R3, #26
2
J-Link>s
3
1FF01754:  FB D5              BPL       #-0x0A
4
J-Link>s
5
1FF0174E:  0A 60              STR       R2, [R1]
6
J-Link>s
7
1FF01750:  C3 69              LDR       R3, [R0, #+0x1C]
8
J-Link>s
9
1FF01752:  9B 06              LSLS      R3, R3, #26
10
J-Link>s
11
1FF01754:  FB D5              BPL       #-0x0A
12
[...]

Ich weiß leider nicht, wie die MCU da hinkommt.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Willst du nicht endlich mal dein Programm zeigen?

Die Sache stinkt doch ganz gewaltig nach Fehler im Programm. Irgend ein 
nicht initialisierter Zeiger oder ein Stack Überlauf oder so. Da kann 
ein feiner Unterschied im Ablauf große Auswirkungen haben.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Willst du nicht endlich mal dein Programm zeigen?
>
> Die Sache stinkt doch ganz gewaltig nach Fehler im Programm. Irgend ein
> nicht initialisierter Zeiger oder ein Stack Überlauf oder so. Da kann
> ein feiner Unterschied im Ablauf große Auswirkungen haben.

Das habe ich schon, siehe meinen Post vom 19.12.2020 13:23. Die 
generierten HAL-Funktionen sieht man allerdings nicht.

Ich hatte doch geschrieben, nach einem Reset komme ich ganz normal in 
das Programm rein. Das ist dann doch kein Fehler im Programm?

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
>> Nein, die Erfolgsquote ist viel höher, aber sie ist nicht 100%! Wobei
>> die Fehlfunktionen vielleicht auch durch "falsches Einstecken"
>> verursacht werden (s.o.).
>
> Was meinst du mit falschem Einstecken? Stellst du den Kontakt her, indem
> du eine Steckverbindung schließt? Das kann alle möglichen Faxen machen
> (die auf dem Oszibild weit vor oder weit nach dem beobachteten
> Zeitfenster liegen).

Ja, ich stecke den Hohlstecker vom Netzteil in den Barrel Jack.

Du meinst also, die wenigen Fehlversuche mit dem Netzteil lassen sich 
auf das Schließen der Verbindung zurückführen? Dann wäre die eigentliche 
Erfolgsquote 100%? Und der Knick doch Schuld?

Ich will immer noch das mit dem RC-Glied am Reset ausprobieren, aber ich 
warte auf die passenden Teile von Reichelt. Vielleicht ist es aber auch 
nicht so wichtig, den STM32 auf Reset zu halten, sondern nach x ms einen 
neuen Reset auszulösen?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
>> Willst du nicht endlich mal dein Programm zeigen?
> Das habe ich schon, siehe meinen Post vom 19.12.2020 13:23.

Oh, ich dachte das sei nur ein kleiner Test zwischendurch gewesen. Also 
dieses kleine Miniprogramm macht schon Probleme? Dann muss man 
vielleicht doch mal die HAL debuggen.

Mein erster Versuch mit der HAL scheiterte an dem generierten 
Initialisierungs-Code, weil dort die Latency für den Flash Speicher 
falsch konfiguriert wurde. Der zweite Versuch (ein paar Monate später) 
scheiterte daran, dass die Teile der Taktkonfiguration in der falschen 
Reihenfolge konfiguriert wurden.

Der erste Eindruck zählt. Bei mir war auch der zweite enttäuschend. Erst 
mein dritter Versuch klappte.

> Ich will immer noch das mit dem RC-Glied am Reset ausprobieren

Mach das. Ist vielleicht besser, als das Fass mit der HAL zu öffnen.

: Bearbeitet durch User
von lars (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Oh, ich dachte das sei nur ein kleiner Test zwischendurch gewesen. Also
> dieses kleine Miniprogramm macht schon Probleme? Dann muss man
> vielleicht doch mal die HAL debuggen.

Das ist auch nur ein kleines Testprogramm, aber darüber reden wir hier 
in diesem Thread.

Die HAL-Funktionen lassen sich nicht debuggen, weil schon main() nicht 
erreicht wird. Der Fehler läge also schon im Startup Code, den ich hier 
angehängt habe. Aber wie gesagt, manchmal klappt's!

> Mein erster Versuch mit der HAL scheiterte an dem generierten
> Initialisierungs-Code, weil dort die Latency für den Flash Speicher
> falsch konfiguriert wurde. Der zweite Versuch (ein paar Monate später)
> scheiterte daran, dass die Teile der Taktkonfiguration in der falschen
> Reihenfolge konfiguriert wurden.

Also ich hatte disher nur ein einziges Mal Probleme mit dem generierten 
Code, und das war die festcodierte Prüfung für Stack und Heap, die bei 
mir nicht gilt, da der Stack im DTCM ist.

>> Ich will immer noch das mit dem RC-Glied am Reset ausprobieren
> Mach das. Ist vielleicht besser, als das Fass mit der HAL zu öffnen.

Ja, ich hoffe, das wird vor Weihnachten noch was. Ich habe hier nur 
Elkos, und ich weiß nicht, ob die auch funktionieren würden.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Ich habe hier nur
> Elkos, und ich weiß nicht, ob die auch funktionieren würden.

Probiere es doch einfach aus.

von Oliver R. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was den Kondensator am Reset betrifft, solltest Du natürlich bedenken, 
dass dieser beim Auslösen des Resets entladen wird, und das über die 
Komponente die den Reset auslöst. Das kann ein z.B. ein Taster sein oder 
ein J-Link, in jedem Fall sollte man im Auge behalten, dass das 
Kurzschliessen des Kondensators einen gewissen Stromfluss bewirkt und 
diesen ggfs. mit einem Widerstand begrenzen. Bei 100nF ist das 
normalerweise noch recht unkritisch, wenn du aber Elkos mit 
vergleichsweise hoher Kapazität dranhängst, kann das durchaus relevant 
sein.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wahrscheinlich ist alles viel einfacher, als gedacht.

Ich habe die ominöse Adresse 0x1ff0xxxx mal im ST-Forum gepostet, und es 
stellt sich heraus, dass dies der Bootloader ist.

Damit ist natürlich BOOT0 (was ich mit fliegendem Aufbau korrigiert 
habe) wieder im Blickpunkt. Ein paar Sekunden nach dem Start ist das 
LOW, aber was genau beim Einschalten passiert weiß ich nicht.

Leider startet der STM32 nach Einlöten eines Drähtchens für BOOT0 nun 
gar nicht mehr, auch mit Netzteil nicht. Allerdings ist er mit dem 
Commander immer noch ansprechbar, und er steckt wieder im Bootloader 
fest.

Ich muss also nochmal die BOOT0-Korrektur löten, aber ordentlich.

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Damit ist natürlich BOOT0 (was ich mit fliegendem Aufbau korrigiert
> habe) wieder im Blickpunkt. Ein paar Sekunden nach dem Start ist das
> LOW, aber was genau beim Einschalten passiert weiß ich nicht.

Oszi?
Es wird Licht am Ende des Tunnels sichtbar.
Btw: welches Gehäuse hat der Chip?

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karl schrieb:
>> aber was genau beim Einschalten passiert weiß ich nicht.
>
> Oszi?
> Es wird Licht am Ende des Tunnels sichtbar.
> Btw: welches Gehäuse hat der Chip?

Ja, aber bei 0,5mm Pitch kann ich den Tastkopf nicht von Hand halten, 
deswegen das Drähtchen. Der STM32 hat ein LQFP-176-Gehäuse.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe des Rätsels Lösung, und sie ist sehr banal.

Da die 10K des BOOT0-Pins SMD sind, hatte ich zuerst den Widerstand quer 
gelötet, damit er nicht mit Vdd in Verbindung kommt, und dann ein 
Drähtchen nach Vss am anderen Ende befestigt. Das war wohl etwas 
wackelig.

Nach dem Hinweis mit dem Bootloader habe ich den SMD-Widerstand entfernt 
und einfach einen bedrahteten Widerstand zwischen Vss und dem BOOT0-Pin 
zugewandten Widerstandspad eingelötet. Sieht abenteuerlich aus, 
funktioniert aber zuverlässig.

Das fröhliche/traurige Ende vom Lied ist, dass jetzt der STM32 auch am 
Bus zu 100% startet! Der Fehler war die wackelige Verbindung von BOOT0 
zu Vss.

Ich möchte mich bei allen, die diese Magical Mystery Tour begleitet 
haben, für das profane Ende entschuldigen, aber natürlich auch herzlich 
Danken. Ohne euch hätte diese Reise ein jähes, vorzeitiges Ende 
gefunden! :-)

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Ich freue mich immer, wenn man am Ende noch die Auflösung des Rätsels 
bekommt. Wird leider vor lauter Freude oft vergessen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.