Ein "Sorry" hier für die beiden handgezeichneten Schaltungen, aber das ging so einfach schneller und zum Darstellen, reicht das glaube ich ausreichend. Mein Problem / Anliegen (oder wie man das bezeichnen mag) hängt eigentlich mit einem anderen Thread den ich in Projekte und Code erstellt habe und bezieht sich auf einen Bootloader mit CH32V003. Da aber die Fragestellung grundsätzlicher Natur ist und das auch andere Mikrocontroller betreffen kann (mein Problem hatte ich auch schon mit einem ATtiny serie0), jetzt hier einmal die Frage grundsätzlich. Ich habe folgendes Szenario: Weil ein Reset über einen Reseteingang des Controllers nicht funktioniert, dieser startet nur die User-Software neu, springt aber hier bei nicht in den Bootsektor, kann ein Aktivieren des Bootsektors nur durch ab- und wieder anschalten der Betriebsspannung erfolgen. Hierbei stellt sich das Problem, dass bei abgeschalteter Betriebsspannung der Mikrocontroller an den Pins Rx und Tx an eine USB2UART-Bridge angeschlossen ist. Da das letzte gesendete Bit auf einer seriellen Schnittstelle ein Stopbit ist, bleibt der Logikpegel von seitens der Bridge auf 1. Schaltet man nun die Versorgungsspannung des Controllers ab, so können unterschiedlich USB2UART-Bridges (ich habe CH340, FTDI, PL2303 getestet) unterschiedliche Ströme liefern. Ein Strom in den Rx Anschluss des Controllers kann bei ungeschickten Bedingungen dazu führen, dass dieses dem Controller als Betriebsspannung reicht und er von daher nicht in den Boot-Sektor springt. Zu diesem Zweck habe ich meine "PowerOn" Schaltung in Schaltung 1 (Impuls auf RTS sorgt dafür, dass die Versorgungsspannung des Controllers kurzfristig abgeschaltet wird) dahingehend erweitert, dass der Rx Anschluss des Controllers über einen Widerstand R4 auf logisch 1 gesetzt wird, der aber an der Betriebsspannung des Controllers hängt. Somit wird bei einer seriellen Übertragung die logische 1 über diesen PullUp-Widerstand geliefert. Wird eine 0 gesendet, so ist dieser Pegel der Diode D1 wegen auf ca. 0,7V. Die Datenübertragung funktioniert fehlerlos, bei abgeschalteter Betriebsspannung liegen als Betriebsspannung dann eben diese ca. 0,7V an, was dem Controller nicht als Versorgungsspannung reicht. In Schaltung 2 habe ich einen kleinen Controller verwendet, der den Impuls von RTS aufnimmt und entsprechend die Transistoren T1 und T2 schaltet. Wird hier die Betriebsspannung abgeschaltet, sperrt nicht nur T1, sondern T2 schließt auch die Rückwärts über den Rx Anschluss entstehende Spannung kurz. Hier bleibt dann nur noch eine Versorgungspannung von ca. 0,2V am Controller stehen (als "Reset-Controller hatte ich zum Experimentieren PFS-154 und ATtiny13 verwendet). So, eigentlich (aber nur eigentlich) gefällt mir Schaltung 1 besser, weil sie deutlich weniger Bauteile verwendet und auch weniger Platz auf einer Platine, die ich jetzt doch routen mag benötigt. Allerdings hat sie einen großen Haken (der mir nicht schmeckt): Der Controller hat natürlich noch weitere GPIO Pins. Hier kann es dann durchaus sein, dass am Controller eine Schaltung hängt, die ebenfalls den Controller rückwärts speisen könnte und dann kann es hier wieder sein, dass der Controller von einem GPIO seine Betriebsspannung erhält. In Schaltung 2 besteht dieses Problem nicht, da dort der NPN-Transistor die Betriebsspannung grundsätzlich kurzschließt. Was schmeckt mir daran nicht: Zum einen der Platzbedarf, den ein zusätzlicher SOIC-8 Baustein benötigt (plus Hühnerfutter), sowie die Frage, welchen Controller ich dafür verwenden soll. Wäre das nur für mich alleine, würde ich in Schaltung 2 den PFS-154 wählen, weil er billig ist. Ein ATtiny13 kostet mittlerweile schon mehr als einen Euro, einen ATtiny der serie 0 werde ich morgen ausprobieren. Das es für eine derart kleine Aufgabe des An- und Ausschalten einer Spannung eines Controllers bedarf, der dann ca. 4 bis 5 mal soviel kostet wie der eigentliche Zielprozessor finde ich dann dämlich (s irgendwie habe ich mir in den Kopf gesetzt, dass das ganze auf einer Platine inkl. der Platine nicht mehr als 1,50€ kosten soll ... als Herausforderung eben. Das ganze wäre dann eine Art "Arduino 32nano für Arme") Da das ganze auch als Nachbauanleitung (irgendwann) herhalten soll werde ich hier mit dem PFS-154 nicht so recht warm, weil ich annehme, dass nicht wirklich viele eine Möglichkeit haben, einen PFS-154 zu flashen (gleiches nehme ich allerdings auch für einen ATtiny serie 0 an, der in diesen Bastler / Maker - Kreisen irgendwie scheinbar noch nicht in dem Umfang wie die klassischen AVR's angekommen ist). ------------------------------------------------------- So, und weil viele Augen mehr sehen als 2 hier dann (endlich) die Frage: Wie würdet ihr das lösen, gibt es eine kurze knackige Schaltung (mit Transistoren) die das löst? Vielleicht seh ich vor lauter Bäumen die Lösung nicht !
Angehängte Dateien:
74LVC1G34, 74LVC2G34 oder 74LVC3G34 an die Ein- und Ausgänge? (Ja, ich habe die Einschränkung "mit Transistoren" ignoriert, andererseits sind in den ICs welche drin.)
:
Bearbeitet durch User
Angehängte Dateien:
-
IMG_20250617_232331.png
59 KB -
IMG_20250617_232521.png
76 KB
schwarz auf Packpapierbraun? Ernsthaft? Dann wenigstens editieren ...
Thorsten S. schrieb: > schwarz auf Packpapierbraun? Ernsthaft? > Dann wenigstens editieren ... Das ist kein Packetpapier, es war hier dunkel... aber danke fürs Aufhellen. Das war ein 4H Bleistift und ich mußte da den Kontrast hochdrehen, damit man da sehen kann. Ich habe mir weiter Gedanken zur Schaltung gemacht und bin am Überlegen, ob folgende Simulation in der Realität funktioniert: https://www.falstad.com/circuit/circuitjs.html?ctz=CQAgjCAMB0l3BWcMBMcUHYMGZIA4UA2ATmIxAUgoqoQFMBaMMAKABcRCUAWcYlTgkJ8BVJiAYwheSGG7ccM7Nm4oIk6IUgY8ebmRIFi2QsLBwQAEzoAzAIYBXADZt2nHiGxpBwr1Srq3NDYeKaE3IQYKMR4OnhIUjgR3AQhXghoeMhU1vbOrgDuPiCZxShCUCxFhBXlwjW+kLyQVWUVGBklFS0ATiAdAtidAyDcXlDZcCwA5v2dYwIjyRMtsw2jFuvL-iwASsVgKFnr4Ssb1P5Q0Ait64fHFWAYwr2enX5vAtwWVChoLUURkNFp06pVAaCKngwMIwasQNDfCYETDRqcdgAHFGwqGo5RmM7meDwFgAZ0+IgpxBe4BAbB6DjoeypvnmWUu3wuK2urQyWTA-AoWkpr0RXWEYvuE2UJP2kqO2M4zQmnIS3JufSEAUFXF4AtEk1eus83i1JsuRKm2AwVHW+OK3wCK1awMpfJFLEsoxk5qFVA+AlyjhcMwpjrD6PBFI+rv1UdjgrBcfhYPtYO2lSxScTFXtEAtxJJRVdHxS-u8LSAA
F. P. schrieb: > 74LVC1G34, 74LVC2G34 oder 74LVC3G34 an die Ein- und Ausgänge? (Ja, ich > habe die Einschränkung "mit Transistoren" ignoriert, andererseits sind > in den ICs welche drin.) Du meinst an die Anschlüsse der USB2UART-Bridge? ... da ist dann eine "Fremdversorgung" immer noch möglich
Ralph S. schrieb: > F. P. schrieb: >> 74LVC1G34, 74LVC2G34 oder 74LVC3G34 an die Ein- und Ausgänge? (Ja, ich >> habe die Einschränkung "mit Transistoren" ignoriert, andererseits sind >> in den ICs welche drin.) > > Du meinst an die Anschlüsse der USB2UART-Bridge? ... da ist dann eine > "Fremdversorgung" immer noch möglich 74LVCxG34 an alle relevanten Eingänge, hier also 74LVC1G34 an RX. Gleiche Stromversorgung wie die geschaltete MCU. Fremdversorgung über RX ist dann nicht mehr möglich. Die 74LVC-Serie ist da speziell, die haben keine ESD-Schutzdioden zu VCC. Auch ein paar andere Serien wie z.B. (WIMRE) 74AHC haben solche anders geschützten Eingänge.
:
Bearbeitet durch User
Bastelprojekt oder Serienprodukt? Im ersten Fall pack einen 100k Widerstand in die RXD-Leitung und du bist fertig.
Da UART im Ruhezustand auf H liegt, würde ich vom CH32V003 GND mit einem FET schalten. Gruß Jobst
Ralph S. schrieb: > Das ist kein Packetpapier, es war hier dunkel An die Lichtverhältnisse passt sich eine Kamera über Belichtungszeit und Verstärkung an. Wie soll es sonst funktionieren, dass man damit sowohl draußen bei Sonnenschein als auch in Innenräumen mit erheblich geringeren Beleuchtungsstärken photographieren kann. Bei zu wenig Licht fängt eine Kamera erstmal kräftig an zu rauschen - tut sie bei dir aber nicht. Falls sie allerdings nicht erkennt, dass der Gegenstand ein weißes Blatt Papier ist, weil der Automatik die Orientierung fehlt, nimmt sie ein mittelhelles Objekt an (Standard: 18% Reflektivität) und man muss manuell eingreifen, damit ein weißes Blatt Papier auch in der Aufnahme als helles Objekt dargestellt wird .
Hermann K. schrieb: > Bastelprojekt oder Serienprodukt? > > Im ersten Fall pack einen 100k Widerstand in die RXD-Leitung und du bist > fertig. Mit Widerständen in der Leitung hatte ich schon versucht gehabt. Danach hatte ich Schaltung 1 gemacht. Bei 100k war die Datenübertragung nicht mehr sicher. Jobst M. schrieb: > Da UART im Ruhezustand auf H liegt, würde ich vom CH32V003 GND mit einem > FET schalten. Den GND Schalten ist nie eine gute Idee (mit N-Channel dann). Grundsätzlich wollte ich statt bipolarer Transistoren FET nehmen, aber ich konnte es schier nicht glauben: N-Channel habe ich massenhaft und P-Channel habe ich nur ein paar wenige Leistungstransistoren. Bei der nächsten Elektronikbestellung (die aktuelle ist noch nicht einmal geliefert) steht das schon auf dem Zettel.
Ich finde, das handgezeichnete Schaltpläne völlig OK sind. Isoliert betrachtet gefällt mir Schaltung 1. Deine Bedenken zur parasitären Speisung durch weitere externe Beschaltung dazu sind völlig korrekt. Das gleiche "Problem" haben alle gängigen Mikrocontroller Boards (außer ESP866, weil dessen ESD Schutz anders arbeitet). Die zweite löst das Problem nicht, und ich sehe auch keine praktikable generische Lösung am Horizont. Für beide Schaltung gilt, dass sie den uC außerhalb seiner Spezifikation betreiben, wenn seine Stromversorgung gekappt wird währen die externe Peripherie noch Spannung an I/O Pins anlegt. Irgenwann wird der uC deswegen kaputt gehen. Die internen ESD Schutzdioden können durchbrennen, kurz danach gehen I/O Pins bei kleinster Überspannung (z.B beim Anfassen) kaputt. Der parasitäre Strom kann einen Latch-Up Effekt auslösen (Kurzschluss innerhalb des IC). Also wenn du offen für nicht speziell angepasste Peripherie sein willst, dann lass es bleiben. Dann muss der Benutzer halt manuell das Netzteil aus schalten. Damit kann man leben. Wenn du alle Pins vor Rückspeisung schützen kannst, dann mache das. Aber wirklich mit allen Pins.
Nicht zu Ende gedacht, war abgelenkt.. Rx über einen NPN schalten?
:
Bearbeitet durch User
Ralph S. schrieb: > Weil ein Reset über einen Reseteingang des > Controllers nicht funktioniert, dieser startet nur die User-Software > neu, springt aber hier bei nicht in den Bootsektor Das ist aber ein seltsamer µC. Ich kenne nur solche, wo externer Reset und Power-on identisch reagieren. Es gibt dann noch solche, die per Fusebit den externen Reset disablen können, um einen zusätzlichen IO-Pin zu erhalten.
Normalerweise sterben die Schutzdioden nicht so, daß sie hochohmig werden, sondern sie werden zum glatten Durchgang. Ich habe bei einem AVR mal einen Portpin zerschossen und der Rest des µC hat das scheinbar klaglos überstanden (aber keine Ahnung wie zuverlässig der Rest des µC dann auf lange Sicht noch ist). Auf dem kaputten Pin konnte man dann prima eine interne 1W-Heizung aktivieren wenn man ihn auf HIGH schalten wollte. Sehr gut für Deep-Space-Missionen (wobei ich nicht denke, daß der µC die Strahlung lange übersteht wenn man ihn nicht dagegen härtet), im gemäßigten Klima auf der Erde eher unpraktisch.
Ralph S. schrieb: > bezieht sich auf einen Bootloader mit CH32V003. Nö, es bezieht sich allein auf Deinen ganz speziellen Bootloader. Warum verlinkst Du ihn dann nicht? Beitrag "CH32V003: serieller Bootloader" Das Problem allgemein ist ja schon gegessen. Entweder eine Diode mit Pullup oder ein Transmission Gate, was ohne VCC in tristate geht. Oder ein Logik-Gate, was Vin > VCC erlaubt. Solche Trenner-ICs bei VCC = 0V habe ich schon mal gesehen, aber die dummen KI-Suchmaschinen finden sowas zum Verrecken nicht mehr, sondern nur ein Patent und nen Haufen anderen unpassenden Schrunz.
:
Bearbeitet durch User
Ganz allgemein erstellt man einen Bootloader so, daß er unabhängig von der Resetquelle eine Bedingung abtestet, um im Bootmodus zu bleiben oder die Applikation zu starten. Das kann ein IO-Pin sein oder das Ablaufen einer Wartezeit, in der ein Kommando empfangen werden muß. Jede Resetquelle führt erstmal immer dahin oder auch ein API-Call aus der Applikation heraus.
Ich mache es oft so, dass ich den UART mit einem 74LVC2G241 isoliere (der unterstützt Partial Power Off und bringt 5V Toleranz mit). https://www.ti.com/product/de-de/SN74LVC2G241 Zum Schalten der Versorgungsspannung würde ich einen Load Switch wie TPS2041B/TPS2051B nehmen. Der bringt noch Überstromschutz mit, was nie eine schlechte Sache ist. Gibts auch im SOT23-5 Package. https://www.ti.com/product/de-de/TPS2041B fchk
Bei meinen AVR-Boards, mache ich es immer so, daß die Applikation einen Resetbefehl erhält und darauf den Watchdog auf 16ms setzt und in eine Endlosschleife läuft. Der Bootloader löscht vor dem ersten Page-Erase ein Byte im EEPROM, damit er weiß, die Applikation ist ungültig. Wird das Flashen vorzeitig abgebrochen, bleibt er also immer im Bootmodus. Die VCC zu schalten, habe ich noch nirgends implementiert.
Alexander schrieb: > Würde nicht ein Pull-down reichen? Absolut korrekte Antwort: JEIN. In manchen Fällen genügt der PullDown eben nicht! Peter D. schrieb: > Das ist aber ein seltsamer µC. > Ich kenne nur solche, wo externer Reset und Power-on identisch > reagieren. > Es gibt dann noch solche, die per Fusebit den externen Reset disablen > können, um einen zusätzlichen IO-Pin zu erhalten. Na ja, für mich war das auch "neu" (kannst du aber auch gerne im DaBla für CH32V003 nachlesen). Ich habe zwar den externen Reset gedisabled (hier heißt das dann nicht Fusebit sondern Optionbyte), aber das habe ich erst gemacht, als mir klar war, dass ich mit dem Resetpin nichts mehr anfangen konnte. Einen Reset über einen Reset-Pin wäre mir am liebsten gewesen.
Peter D. schrieb: > Ganz allgemein erstellt man einen Bootloader so... > Jede Resetquelle führt erstmal immer dahin Das hätte der Ralph ja auch gerne so, aber da der Reset Pin im Gegensatz zu deiner Idealvorstellung keinen richtigen Reset auslöst, hat er keine andere Wahl, als einen Workaround zu suchen.
:
Bearbeitet durch User
Ralph S. schrieb: > kannst du aber auch gerne im DaBla > für CH32V003 nachlesen Ich finde nichts. Kannst Du mal den Link und die Seite nennen?
Ralph S. schrieb: > Na ja, für mich war das auch "neu" (kannst du aber auch gerne im DaBla > für CH32V003 nachlesen). Ich habe zwar den externen Reset gedisabled So ist das bei einigen WCH MCUs implementiert, nur ein PWR On kann zur Aktivierung der Bootloader verwendet werden. Ist bei MCS51 Versionen von WCH auch so. Es scheint Teil ihres Schutzkonzepts zu sein. Es gibt irgendwo bei WCH auch einen Vorschlag zu dem Problem der Fremdspeisung, mal schauen ob ich das finde. Ansonsten einfach mal im WCH Forum posten. Das ist inzwischen auch recht gut zu bedienen, wenn man die automatische Übersetzung einschaltet. Die FAEs antworten auch auf englische Posts.
Thomas Z. schrieb: > nur ein PWR On kann zur > Aktivierung der Bootloader verwendet werden. Zumindest beim CH32V003 gibt es lt. Dabla mindestens noch eine weitere Möglichkeit: "1.4.2 On-chip Memory and Boot Mode ... Support Boot and user code jumping to each other."
Also ich habe ja auch Abschaltungen verbaut. Bei mir hat der Abwärtswandler bzw. der LDO immer einen INH oder EN. Das Problem mit einem Signal welches getrennt werden muss sobald der µC stromlos ist hatte ich auch schon. Das liese sich mit einem Transistor als Schalter lösen. Beitrag "Re: ESP32 externer Watchdog Reset stört Flashvorgang"
Peter D. schrieb: > Support Boot and user code jumping to each other." richtig ist halt das Henne - Ei Problem. Du kannst in den Loader springen falls du eine App drauf hast die das kann. Die Lösung von Ralph hat den Charme dass Sie immer funktionier egal was im User Flash gerade installiert ist. Bei WCH ist das übrigens unter IAP im EVT zu finden. Allerdings ist vieles bei WCH nur schlecht dokumentiert, und in der englischen Version der Website ist längst nicht alles verfügbar oder veraltet.
Thomas Z. schrieb: > richtig ist halt das Henne - Ei Problem. Du kannst in den Loader > springen falls du eine App drauf hast die das kann. Die Lösung von Ralph > hat den Charme dass Sie immer funktionier egal was im User Flash gerade > installiert ist. ... das war der Sinn und Zweck der Übung! So, scheinbar hat Peda ein Datenblatt gefunden für alle Interessenten hier aber dennoch noch einmal ein Link (WCH gibt keine Errata heraus, stattdessen haben sie Versinosnummern für ihre Datenblätter und Reference Manuals): https://www.jjflash.de/ch32v003/ch32v003_usermanual.pdf https://www.jjflash.de/ch32v003/ch32v003_reference.pdf Es gibt keine Stelle am Stück, aus der hervorgeht, dass ein Resetsignal auf Pin nrst nicht in den Bootloader springt, dieses "darf" man sich aus den Optionbytes zusammensuchen (und da habe ich dann natürlich einiges bei CH32FUN abgespickelt). Erste Versuche bspw. zum Bootloader waren in dieser Art: ein 3 maliges Blinken auf einer LED, bevor ein Userprogramm gestartet wird (in meinem Fall habe ich "Hallo Welt" auf der UART ausgegeben. Hat man den Chip bestromt, hat das zuerst 3 mal geblinkt und danach gab es die Ausgabe auf UART. Wurde dann ein nrst ausgelöst, wurde "Hallo Welt" erneut ausgegeben, ohne dass das Blinken im Boot-Sektor gestartet wurde. D.h. ein Reset wurde nur für das gesamte System ausgeführt, bezog sich aber nicht auf auf den Bootsektor. Hier ist dann zu sagen, dass das Konzept des Bootsektors von WCH ein anderes ist, als bspw. bei den AVR's oder den STM32. Bei AVR ist der Bootbereich hinter dem Userbereich und ist ein Userprogramm zu lange und man hat irgend etwas "verbockt", kann man den Bootbereich beim AVR locker überschreiben (und damit den Bootloader löschen). Prinzipiell ist das beim STM32 ähnlich. Beim CH32 ist der Boot-Bereich vom User-Flash abgetrennt (was man auch am nicht zusammenhängenden Speicherbereich gut erkennen kann). D.h. die 1920 Byte im Bootsektor sind (zumindest nicht so ohne weiteres) vom Userprogramm nicht zu verwenden. Nachdem ich das evaluiert hatte, hatte ich (schweren Herzens) den nrst-Pin deaktiviert um einen weiteren GPIO zu gewinnen. ------------------------------------- Das eigentliche Thema, die Abschaltung der Versorgungsspannung des Controllers, geht wohl auch in seine "Endphase", da ich glaube eine gute Kompromisslösung gefunden zu haben. Da jetzt aber erst einmal ein langes Wochenende ansteht, kann ich dazu erst nächste Woche, falls das jemanden interessiert, etwas schreiben / zeigen. Von daher: ein schönes Wochenende an die, die morgen Feiertag haben. Gruß, Ralph
Ralph S. schrieb: > Weil ein Reset über einen Reseteingang des > Controllers nicht funktioniert, dieser startet nur die User-Software > neu, springt aber hier bei nicht in den Bootsektor " Laut CH32V003 Datenblatt Kap 1.4.2 "On-chip memory and boot mode" sollte sich das doch programmieren lassen, da du zwischen Boot- und User-Code hin und her springen kannst.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.