|
Anzeige
|
ESP32 externer Watchdog Reset stört FlashvorgangIch habe einen externen Resetgenerator im LDO den ich gern nutzen würde, klappt auch alles soweit. Die main loop() toggled den Watchdog und der Reset Pin des LDO ist mit dem EN Pin des ESP32 DevBoard verdrahtet. Nun möchte ich das Signal unterbrechen mit einem NPN der über GPIO0 angesteuert wird, so dass sich der ESP32 flashen lässt. Problem der Reset funktioniert dann nicht mehr, Vce geht nicht bis auf GND runter. Zeig die Schaltung, die da Probleme macht. Bennne die Bauteile mit Namen und Typbezeichnungen. Ist nur Prosa noch nicht im Schaltplan.
Angehängte Dateien:
Welche Signale willst du mit welchen Pegeln wie/wann ansteuern? Was soll am EN ankommen, wenn der GPIO angesteuert wird?
Sondern wie weit? Braucht der EN-Pin evtl. einen Pulldown? Oder kannst du den einfach so "offen" lassen?
Welcher LDO? Was ist "Reset"? Ist der high- oder low-aktiv?
Wo ist diese Vce? Kann ich diese Prosa so lesen, dass du am EN Signal dauernd low haben willst, wenn der Pin "angesteuert" wird? Falls ja, warum machst du es dann nicht einfach so:
TLE4271, im Datenblatt steht: Reset Output; the open collector output is connected to the 5 V output via an integrated resistor of 30 kΩ ESP32 GPIO0: must be LOW to enter flashing mode https://randomnerdtutorials.com/esp32-pinout-reference-gpios Mit Vce meine ich die Kollektor-Emitter-Spannung am Transistor, z.B. BC547. Wenn ich mit Arduino IDE flashen will soll der GPIO0 doch als Output LOW den Transistor ausschalten. Der Reset (Active Low) vom Watchdog wird dann nicht an den ESP32 durchgeschaltet (falls einer auslöst) Im Normalbetrieb ist der GPIO0 HIGH und der Transistor sollte mit 3,3V gesättigt sein. Ich geh jetzt noch mal rein messen, antworte gleich..
dann nutze ein Photomos Relais, das schaltet erst durch wenn du genügend IR Strom auf die LED freischaltest also wenn die CPU aus dem Reset ist und das normale Programm läuft, nur wie soll es ohne Reset dort hinkommen? Sieht nach einem typischen Logikfehler oder Trollthread vom Alex aus
Und was soll dann die Geheimniskrämerei und nennst ihn nicht endlich? Dem kann ich mich nur anschließen: Dein Problem wird am schnellsten gelöst, wenn Du hier zumindest den relevanten Teil des Schaltplans eindeutig und mit allen notwendigen Informationen darstellst! Falls ich es bisher richtig verstanden habe: Du willst den WD per Software abschalten, um ungestört Deinen Prozessor flashen zu können? Einen WD per Software abschaltbar zu machen, schränkt den Sinn des WD ziemlich ein. Und wenn es unbedingt sein muß, wegen aufspielen von Software aus der Ferne, dann muß das wirklich wasserdicht sein. Wie gesagt, so habe ich es bisher verstanden.
Hab jetzt einen BC337-25 versucht zu messen, leider bekomme ich es nicht gemessen da ich den Resetgenerator auf 1 Sek gestellt habe, und das DMM ist etwas träge. Also der Reset Pin liefert 3,3V als HIGH und 0V als Reset. Der EN Pin des ESP32 hat 4V als Floating. Verdrahte ich die Pins direkt miteinander sind es 4V. Reset wird korrekt ausgelöst. Funktioniert wie es soll. Setze ich den NPN dazwischen (wie im Schaltplan s.o.) und beschalte die Basis mit 3,3V und 1k löst der Reset nicht mehr aus. Ich messe irgendwas mit 1,6V am Kollektor wenn der Reset auslöst. Setze ich den Reset Pin gewaltsam auf GND so bricht die Basisspannung zusammen auf 0,64V obwohl 3,3V anliegen. Durch den kleinen Basiswiderstand zieht es außerdem den GPIO runter auf 0,7V was nicht sein darf. Am Emitter messe ich 4V d.h. der Transistor schaltet den Reset nicht durch obwohl er es sollte.
Jein, der GPIO0 muss zum flashen auf Low gezogen werden. Das alte Arduino 1.8.19 konnte das irgendwie automatisch, bei der neuen Arduino IDE 2.3.6 muss man auf dem DevBoard einen Taster zum flashen betätigen. Frag mich nicht wie das geschaltet ist, müsste ich mal den Schaltplan dazu finden. Der Resetgenerator kann ruhig weiterlaufen, soll aber während des Flashvorgangs ignoriert werden. Bisher muss ich immer das Kabel abziehen. Es soll aber alles auf ein PCB demnächst und einen Jumper brauche ich nicht unbedingt. Dann verzichte ich lieber auf den Watchdog.
Darf ich dich fragen, was dir an dem eingebauten Wachhund nicht gefällt? Nimm einen passenden Watchdog, z.B. XC6122F745MR-G. Mit EN = low schaltet der Watchdog ab, Poweron-Reset bleibt weiterhin aktiv. Reset ist open-drain, d.h. mit einer Diode kannst Du das Reset vom Programmer hinein verknüpfen. https://www.digikey.de/de/products/detail/torex-semiconductor-ltd/XC6122F745MR-G/4372353
Dazu werden die Signale DTR und RTS der UART benutzt: "The DTR and RTS control lines are in turn connected to GPIO0 and EN (CHIP_PU) pins of ESP32."
Andersrum. Warum sollte ich einen internen nutzen wenn ich einen externen Watchdog gratis zur Verfügung hab? Damit gehe ich solchen Problemen und Tests aus dem Weg.
Sieht gut aus. Muss aber auch mit Transistor gehen.
ach dann hast du ja kein Problem?
Das bedeutet ja nur, dass der GPIO ein Eingang ist, der beim Booten auf low gehalten werden muss, um in den Programmiermodus zu kommen.
Welchen Pegel gibt der GPIO0 denn beim Flashen aus? Wer sorgt dafür, dass er diesen Pegel ausgibt?
Also gibts ja offenbar schon einen Schaltplan ohne diesen Transistor. Dann kritzle das doch in diesen Schaltplan rein, statt aus 1 einzigen Bauteil eine Label-Hell zu machen. Ah nee, einen Gesamt-Schaltplan im Forum posten, das muss ich mir nicht antun. Solche Anfängerfehler macht man hier nur genau einmal im Forum..
Ich wünsche dir viel Erfolg auf deinen Wegen. Ich hab hier was gefunden ist so ähnlich. Nur ist bei mir ein CH340 drauf.
Wer spricht denn von einem Gesamtschaltplan? Das möchte ich mir auch nicht antun. Aber wenigstens so viel vom Schaltplan, dass man kapiert, was deine Worte bedeuten.
Und Glück. Es ist augenscheinlich nötig. Ich weiß nicht was daran so schwer zu verstehen ist.. ich möchte einen Transistor als Schalter.
Angehängte Dateien:
Wer redet von Gesamtschaltplan. Wenn du den relevanten Teil unbedingt für dich behalten willst, tue das. Dein Problem kannst du auch gleich dazu gesellen. Von "Anfänger" zu reden und schon bei der Messung von ein paarhundert Millivolt zu scheitern, passt zusammen.
Wenn dich aus unerfindlichen Gründen ein bisschen Vce stört, nimm einen MOSFET. Hast du dir deine Schaltungsidee einmal in der Simulation angesehen ( z.B. mit LTSpice) und die Ansteuerung geprüft? Was soll das Zeugs unterhalb des BJT darstellen?
Wie soll ich es denn messen wenn der Reset hart (RC Glied) auf 1 Sekunde getaktet ist? Das Multimeter zeigt es nicht richtig an. Muss ich das Oszilloskop erstmal anschließen.
Bekomme ich damit GND auf GND geschaltet? Das wäre schon die Lösung.
Ich hab sie ja schon aufgebaut, da muss ich nicht mit Modellen rumfummeln .
dann ist doch alles gut oder wo ist dein Problem? lernen was Transistoren tun willst du ja nicht, die Logik durchdenken willst du auch nicht! Beitrag "Re: ESP32 externer Watchdog Reset stört Flashvorgang" Es ist doch kein Fehler in meiner Logik? Ohne Transistor funktioniert der Resetgenerator. Zum Flashen muss ich das Dupont Kabel vorher abziehen. Danach wieder dran stecken. Den Vorgang sollte man doch mit einem Transistor automatisieren können. Da es Active Low (also GND) schaltet, war ein NPN logisch. Die Fragen von Lothar sind natürlich berechtigt, ich weiß nichts über den GPIO0, ob der als Input oder Output konfiguriert ist keine Ahnung. Aber er hat wohl einen internen Pull-up, das ist doch schon mal gut. Jetzt hab ich in einem alten Thread den MOSFET TN0702 als Vorschlag gefunden. Habe aber Probleme das Datenblatt zu verstehen. Die Beschaffung ist auch mau (ser, Sammelbestellung gerade verpasst) gibt's Alternativen im TO92 Gehäuse?
Schlampig gezeichnet. Ist genau dasselbe wie im ersten Bild. Ein Basiswiderstand zwischen Transistor und MCU.
Angehängte Dateien:
Ist es sicher, dass der EN Eingang dieses ESP32 zum Resetten taugt? Ich frage, weil das beim ESP8266 nämlich nicht der Fall ist. Ich hatte nach Stack Overflows beobachtet, daß der Pin nicht mehr reagierte. Der Reset Eingang hingegen funktionierte wie er soll.
Ich fürchte doch. Denn der Basis-Strom kommt am Emitter heraus. Dort hast du immer einen High Pegel, sogar wenn der Kollektor unbeschaltet ist. War sicher nicht so gedacht. Ja der EN Pin funktioniert. Wenn ich das zweite Kabel abziehe zwischen WO und WI dann wird im Sekundentakt ein Reset ausgelöst. Sieht man auch schön im Serialmonitor. Ist nur komisch dass er unbeschaltet auf 4V rumfliegt.
Ja das habe ich schon festgestellt. Muss eigentlich auf GND runter. Ich habe aber immer eine Vce. Deswegen suche ich nun einen MOSFET für 3V im TO-92 Gehäuse.
Angehängte Dateien:
Die ganze Schaltung ist doch Käse. Der Reset Ausgang des Watchdogs hat einen internen Pull-up auf 5V. Der ESP32 verträgt aber nur 3,6V. Außerdem missbrauchst du den Enable-Eingang zum Resetten. Ich habe den Resetgenerator schon auf 3v3 runter skaliert. Der EN Pin ist für den Reset gedacht, mit dem wird der AMS1117 auf dem ESP32 DevBoard abgeschaltet. Ist schon alles richtig so gemäß Datenblatt. Es funktioniert ja auch. Nur soll es während des Flashvorgangs nicht funktionieren... :) Bei dieser Schaltung müsste man das GPIO-Signal für die Basis vorher noch invertieren.
Angehängte Dateien:
Dann hätte ich aber noch immer Vce > 0V oder nicht? Mein Vorschlag
Angehängte Dateien:
Höchstens 0,1 Volt, aber das dürfte sich auf den EN-Eingang nicht störend auswirken, weil 0,1V als Low eingestuft wird. Ich habe den BC337-25 gerade nachgemessen. Vce sind 0,2V. Bist Du Dir sicher dass es nicht GND sein muss?
kann ich testen, verstehen tue ich ihn nicht. Der ESP32-Upload läuft doch inzwischen (zumindest wenn man esptoolpy verwendet) über einen kleinen Loader, der zuerst aufgespielt wird. (flasher_stub Ordner im esptool) Saubere Lösung wäre wohl den anzupassen, dass der den externen Watchdog auch zurücksetzt solange noch Daten übertragen werden. Nur das Hochspielen vom Stub mit ein paar kb müsste der Watchdog überstehen, das läuft noch über den Loader im ROM. Nachteil: Deine Hardware lässt sich dann nur mit "deinem" Programmiertool beschreiben, andere Upload-Tools werden vom Watchdog abgewürgt. Ich hab jetzt noch mal an einem anderen GPIO12 getestet mit 10k pull-down und dem NPN. Flashen klappt, booten klappt, keep alive klappt. Der Reset funktioniert aber nicht sauber, läuft 4-7 mal an und hängt sich irgendwann auf. Ich denke die 0,2V sind das Problem.
Du wirst niemals Uce=0V erreichen. Selbst bei heftigster Übersteuerung nicht.
Du denkst falsch. 0,2V sind auch für einen 3V3-CMOS-Eingang ein bombensicheres Low. Die tatsächlichen Schaltschwellen lassen sich aber ganz leicht im Datenblatt des µC nachschauen, da muss man gar nichts denken.
Gar nicht, also auch nicht mit einem MOSFET? Ich frage weil das von Rainer W. (rawi) als Vorschlag kam.
Ich bin mir nicht sicher ob der EN Pin überhaupt ein GPIO ist. Falls ja, dann sind es keine sauberen Flanken oder eine Racecondition. GPIO12 sollte aber HIGH sein. https://docs.espressif.com/projects/esptool/en/latest/esp32/advanced-topics/boot-mode-selection.html
Okay zu CHIP_PU findet man was im Datenblatt. Mal ist von Active High die Rede und mal von Active Low. Da steht min: - typ: - max: 0.6V
Da hast du mein vollstes Verständnis. Im idealen Fall bekommst du einen Hinweis, dass dein Schaltplan nicht korrekt gezeichnet ist und den Link in die Forumseigene Wiki, wie man einen Schaltplan zeichnet: Links Eingang, rechts Ausgang, oben Plus, unten Masse. Das ist noch konstruktive Kritik, solange es dabei bleibt. Wenn Fehler im Schalplan sind, dann wirst du auch noch darauf hingewiesen. Wenn du dann fragst, warun das ein Fehler ist, dann bekommst du auch noch Hinweise, wenn nicht die ersten bekannten User aufgewacht sind, welche dir von vorne herein die Kompetenz absprechen, und dir sagen, dass du besser wieder in den Sandkasten spielen gehen sollst. Ein weiterer User gibt dir dann einen Tipp, welcher vielleicht nicht gerade der passende ist, weil es bessere gibt, oder weil der wohlgemeint, aber nicht richtig ist... Dann beginnt der übliche Krieg zwischen den bekannten Usern, und dein Thema ist aussen vor. Der wohlgemeinte Tipp wird nicht so beantwortet: "Nicht ganz richtig, sondern falsch ;-)", sondern so: "Du hast keine Ahnung", "lass die Finger weg davon" (wobei das ab und an auch gerechtfertigt ist, um den Darwin-Award demjenigen nicht zu gönnen :-)) Es gibt hier einige Threads, wo mit Engelsgeduld ein Problem erklärt wird, weil der TO wirklich keine Ahnung hat, aber Ahnung bekommen möchte, und dann auch immer wieder nachfragt. Er wird dann zum Troll erklärt. Müsste ich einen Artikel in der Wikipedia über dieses Forum schreiben, dann würde ich nicht gerade die Umgangsformen reinschreiben, aber, dass das Wort Troll das meist missbrauchte Wort hier ist.
Es geht um diese Schaltung (nicht die hier angehängte!): Nemopuk schrieb im Beitrag #7885691:
Q2 invertiert das Reset Signal. Wenn der Eingang vom Watchdog auf LOW gezogen wird, schaltet Q2 ein und zieht den Reset Pin des ESP auf High. Q1 wird durch GPIO0=LOW aktiviert. Er nimmt dem Q2 seinen Basis-Strom weg, um dadurch den Watchdog-Reset zu verhindern. Ich habe allerdings gerade gesehen, daß der ESP32 im Gegensatz zum ESP8266 keinen dedizierten /Reset Eingang hat. Also passt mein Schaltungsvorschlag nicht zum ESP32. Die Beschriftung des "RST" Tasters hat mich in die Irre geführt. Ich habe einen neuen Entwurf angehängt, der meiner Meinung nach funktionieren sollte. Zur Funktionsweise: Normalerweise wird GPIO0 (durch einen 12kΩ Pull-up) auf HIGH gezogen. Wenn dann der Watchdog-Ausgang auf LOW geht, schaltet Q1 ein und zieht den EN Eingang des ESP auch auf LOW. Die Annahme war, das GPIO0 beim Programmieren die ganze Zeit auf LOW liegt (stimmt das überhaupt?). Dann leitet der Transistor nicht, so dass der Watchdog keinen Reset auslösen kann. Die 5V vom Watchdog kommen beim ESP32 nicht an. Nur der LOW Pegel wird durch gereicht. Der HIGH Pegel kommt vom Pull-up Widerstand auf dem ESP32 Board, und der hängt an 3,3 Volt. Der Vorwiderstand vor der Basis wurde so hoch gewählt, damit er das GPIO0 Signal (dessen HIGH Pegel von einem 12kΩ Pull-up kommt) nicht zu stark belastet. Es soll im Ruhezustand auf jeden Fall bei einem HIGH bleiben. An einem Punkt bin ich unsicher: Und zwar könnte es sein, dass der Spannungsabfall an der C-E Strecke zu hoch ist. In diesem Fall würde ich auf einen N-Kanal MOSFET ausweichen und den Widerstand weg lassen. So weit hast du dir das ja auch schon überlegt. PS: Du hast in deinem Schaltungsentwurf C und E vertauscht.
Angehängte Dateien:
Beitrag #7885791 wurde von einem Moderator gelöscht.
Stimmt. Manchmal hat man Tomaten auf den Augen. Hatte ich beim ersten Hinweis nicht gecheckt.
Also ist (unabhägig von high- oder low-active) alles alles unter 0,6V ein Low.
Nein, auch mit einem Mosfet wirst du keine 0(,00000)V erreichen. Das ist aber ja auch nicht nötig.
Der dürfte wohl in allen Fällen ein Eingang sein. Aber es geht ja auch nicht grundsätzlich um den EN Pin.
Entferne das "sollte" aus deinem Satz und stelle sicher, ob/dass der Pin zu dem Zeitpunkt (dauerhaft) den Pegel hat, den du für das gewünschte Verhalten brauchst. Das gilt auch für den zuerst verwendeten GPIO0. Meine Vorgehensweise wäre hier, erst mal die Pegel in einer Logiktabelle dazustellen, die für das gewünschte Verhalten tatsächlich nötig sind. Und dann mit einem geeigneten Messgerät zu kontrollieren, ob die nötigen Signale auch wirklich (und vor allem definiert und dauerhaft) anliegen. Es tut mir Leid aber mit meinem begrenzten Equipment lässt sich das nicht herausfinden. GPIO12 ist anscheinend nicht HIGH, und per Software kommt es zu spät. Die Transistorschaltung von Nemopuk funktioniert jetzt mit 47k. Aber ich konnte es nur mit TX0 testen das scheint der einzige Pin zu sein der wirklich von Anfang an HIGH ist (über USB). DevBoard mit GPIO0 hab ich gar keins mehr da. GPIO2 kann ich noch mal testen.
Angehängte Dateien:
Also das Problem (in meinem Fall Glück) war ich hatte das USB-Kabel dran. Ohne USB-Kabel funktioniert der Resetgenerator augenscheinlich. Das Problem ist, es gibt keinen GPIO der zuverlässig HIGH ist wenn der ESP32 abstürzt. Das USB-Kabel hat den ESP32 zum Absturz gebracht, was den Fehler im Konzept offenbart. Ich brauche also einen anderen Pin. Kann man das USB-Kabel an einem Pin abgreifen? Ich brauche irgendwas externes, nichts was vom Status des ESP32 abhängt.
Was soll der Pin tun? Die Schaltpläne für dein ESP Board liegen sicherlich öffentlich aus. Entweder bist du total verwirrt, oder ich doof. Weiterhin mein Vorschlag:
Natürlich darfst du auch noch ein paar Tage basteln. Das steht allerdings irgendwie im Widerspruch zu:
Damit sollte sich doch diese Frage leicht beantworten lassen: Alexander schrieb im Beitrag #7885949:
Ob da ein für dich befriedigendes ja oder nein rauskommt, KA. Und, schon was neues? Wie? Bei mir? Ja klar! Immer! Hat aber alles nix mit deinem Problem zu tun. Ich weiß nur, dass du in die falsche Richtung gehst, aber das ist nichts neues. Und eine Änderung ist nicht zu erkennen. Verzeih mir aber ich finde den externen Hardware Watchdog besser. Ja, diesen per Software zu umgehen nur zum Flashen war ne blöde Idee. Den komplett durch einen Software Watchdog zu ersetzen ist aber auch nicht zielführend. Ich belasse es bei einem Jumper für den Notfall und versuche es mit OTA.
Ja? Aha! Ist dir auch klar, auf/mit welchem Prozessor Kern der seinen Job macht?
wie geschrieben: Du musst ihn nicht umgehen, sondern nur während dem Flashen auch regelmäßig zurücksetzen. Dasselbe wirst du auch für das OTA-Update umsetzen müssen, das braucht auch länger als so ein typischer HW-Watchdog-Chip warten will. Ich hab mich noch nicht mit OTA beschäftigt. Dachte das läuft nebenher und schreibt im Hintergrund die Partition. Ich hab 1 Sekunde. OTA flashen über WLAN ist problemlos möglich. Das läuft im Hintergrund und der Watchdog wird mit regulärem Programmablauf bis zum Neustart die ganze Zeit bedient. Ist ein Watchdog noch ein Watchdog wenn er über einen Hardware-Timer läuft? Aus der main loop() musste ich den rausnehmen, da mbedtls_rsa_gen_key() so CPU intensiv ist dass der Watchdog ausgelöst hat. Läuft jetzt über LEDC.
Nein, denn der Hardwaretimer läuft ggfs. samt Interupt weiter, auch wenn deine SW fest im Deadlock hängt. :
Bearbeitet durch Moderator
Hm dachte ich mir schon fast. Also muss der Timer automatisch auslaufen. Mal sehen wie ich das gelöst kriege.
Das ist keine gute Idee.
Üblicherweise schaut man, welche Funktion am längsten läuft und spendiert dem Watchdog-Timeout noch 20% Reserve. Ggf. kann man die Funktion auch aufteilen oder man platziert einen Watchdog-Reset an geeigneter Stelle in der problematischen Funktion. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
