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?
Angehängte Dateien:
-
DS0003.PNG
6,6 KB
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 ?
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?
Eine Lösung könnte sein den STM mittels diskreten BOD im Resetmode zu halten bis eine Mindestspannung erreicht ist.
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
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.
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.
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
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.
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... ^^
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.
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).
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.
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
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.
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.
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.
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.
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?
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?
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.
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.
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.
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.
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.
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.
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 ;)
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.
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.
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.
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...
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?
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.
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?
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.
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.
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).
lars schrieb: > Die Idee ist, dass der externe Reset später kommt als der interne (den > ich dann ausschalte). Oder auch nicht, mal sehen.
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.
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
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?
Wolfgang schrieb: > Eine Möglichkeit wäre, ein Supervisor & Reset ICs zu verwenden 1990 hat angerufen. SCNR Das hat der Controller alles drin.
Angehängte Dateien:
-
DS0001.PNG
6,5 KB -
DS0002.PNG
7,3 KB
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.
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.
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.
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.
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 ;-)
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.
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.
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.
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
Angehängte Dateien:
-
optcr_1fff.png
18 KB -
optcr_4002.png
9,6 KB
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?
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.
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?
Keine Ahnung. Für stm32 nahm ich immer das stlink utility. Da konnte man das einfach anklicken.
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.
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)
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.
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!
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.
Angehängte Dateien:
-
DS0005.PNG
12 KB -
DS0003.PNG
15 KB
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?
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?
Angehängte Dateien:
-
DS0006.PNG
12 KB
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?
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.
Angehängte Dateien:
-
VDDRamp.png
19 KB
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).
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.
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.
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.
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.
Angehängte Dateien:
-
debugger.png
25 KB
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.
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.
Angehängte Dateien:
-
DS0007.PNG
13 KB
Ich habe mal den Spannungsverlauf bei meiner alten Platine mit einem LDO NCP-1113(?), die Skala ist etwas größer.
Angehängte Dateien:
-
DS0008.PNG
5,9 KB
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.
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.
Angehängte Dateien:
-
DS0009.PNG
13 KB
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.
Angehängte Dateien:
-
schema.png
11 KB
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.
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?
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).
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.
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.
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.
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.
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.
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?
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?
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.
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.
lars schrieb: > Ich habe hier nur > Elkos, und ich weiß nicht, ob die auch funktionieren würden. Probiere es doch einfach aus.
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.
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.
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?
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.
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! :-)
Ich freue mich immer, wenn man am Ende noch die Auflösung des Rätsels bekommt. Wird leider vor lauter Freude oft vergessen.
Thread beobachten
Seitenaufteilung abschalten
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.