Hallo zusammen, für einen Flightcontroller (für eine Drohne) habe ich eine PCB mit einem STM32F405RGT6 erstellt, bestellt und bestückt. Leider bekomme ich beim verbinden mit der USB-Schnittstelle keine Verbindung zum PC. Heißt es tut sich überhaupt nichts beim Einstecken, am PC wird auch im Gerätemanager nichts erkannt. Nach meinem Verständnis sollte bei einem Fabrik neuen STM32 bei gedrücktem Boot-Button ein COM-Port am PC erkannt werden. Eine gekaufter Flightcontroller mit dem gleichen STM32 wird an meinem PC sofort erkannt. Die 3,3V Spannungsversorgung kommt über einen AMS1117-3.3 der über VUSB versorgt wird (Spannungsversorgung liegt an, gemessen 3,28V). Q1 ist ein CSTCE8M00G52-R0, da ist mir nicht ganz klar wie die Polarität ist, aber das sollte meines Wissen egal sein. Der Schaltplan baut auf diesen Schaltplan auf: https://easyeda.com/mesh.drone/mesh-fc-v1-backup Unterschied zu meinem ist der Spannungsteiler VUSB liegt bei mir an Pin2 und nicht an Pin25 vom STM32 (hab auch schon eine Brücke von Pin2 auf Pin25 gelegt). Und Pin19 ist bei mir auf 3,3V. Die Frage ist jetzt, liegt der Fehler im Schaltplan oder was könnte man machen um herauszufinden was das Problem ist?
Angehängte Dateien:
-
STM32F4.png
60 KB -
PCB.jpg
250 KB
Wozu meinst du, hat "man" sechs Kondensatoren 100nF vorgesehen? Weil man 600nF braucht und 100nF nicht reichen? Du hast offensichtlich die Kondensatoren einfach auf die Platine geklatscht ohne eine winzige Ahnung zu haben wofür sie da sein sollen. Die Kondensatoren sind in netten kleinen Grüppchen platziert wo sie praktisch keinen Nutzen haben. Damit deine Ahnung etwas grösser wird: diese sogenannten Abblock- Kondensatoren gehören direkt an die entprechenden Pins des STM-Controllers (und natürlich direkt an Masse). Schaue dir ein ReferenzDesign bzw. Layout von STM (siehe Nucleo-Boards) an und verstehe wie das sein muss (nicht sollte sondern muss).
Julian B. schrieb: > Leider bekomme ich beim verbinden mit der USB-Schnittstelle keine > Verbindung zum PC. Heißt es tut sich überhaupt nichts beim Einstecken, > am PC wird auch im Gerätemanager nichts erkannt. Für gewöhnlich erkennt das OS im PC ein an den USB gestecktes Gerät daran, daß eine der Signalleitungen vom Gerät über einen 1k5 hochgezogen wird. Erst dann fängt das OS an, über den USB das vermutete Gerät zu fragen "hallo, du da, was bist du denn?" und erst dann, wenn das Gerät antwortet "ich heiße pid&vid und bin ein virtueller COM-Port" und das OS in seinem Keller den zuständigen Treiber findet, dann kommt ein für die Anwendungen verwendbarer COM-Port dabei heraus. Den 1k5 gegen 5 Volt kann man auf der LP finden, es kann aber auch sein, daß dieser von einem Transistor o.ä. geschaltet wird, damit das Gerät selber bestimmen kann, ob und wann es vom PC aus gesehen werden will. Und für die o.g. Befragung braucht es ein passendes Programm im µC. Das kann auch ein Teil des Bootladers sein, aber es muß laufen. Also ist in deinem Falle auch die Boot-Beschaltung wichtig. So etwa. Und nun ist es wieder an dir, deinen Fehler zu finden. W.S.
Julian B. schrieb: > Nach meinem Verständnis > sollte bei einem Fabrik neuen STM32 bei gedrücktem Boot-Button ein > COM-Port am PC erkannt werden. Nein kein COM Port. Der Bootloader nutzt das DFU Protokoll. Das Board sollte aber wenigstens als "unbekanntes" Gerät im Gerätemanager auftauchen, zusammen mit einem "Palim" Geräusch (bei Windows). Wenn es stattdessen "Pilam" macht, hast du eine Kommunikationsstörung. Linux ist in solchen Fällen übrigens recht gesprächig. Du kannst ein Live System (z.B. Ubuntu) von USB Stick booten und direkt nach dem Einstecken des USB Kabels "sudo dmesg" eingeben. Dann siehst du die Kernel-Meldungen dazu. Wenn der PC das Anstecken des USB Kabel überhaupt nicht bemerkt, wurde der Pull-Up Widerstand nicht aktiviert. Der Bootloader tut das aber. Also könnte das ein Indiz dafür sein, dass der Mikrocontroller überhaupt nicht arbeitet. Die Stromversorgung hast du geprüft. Prüfe auch die Spannung am Reset Eingang und am Boot0 Pin. Schwingt der Quarz-Oszillator, auch wirklich auf 8 MHz? "An external clock multiple of 1 MHz (between 4 and 26 MHz) is required for CAN and DFU bootloader execution after the selection phase." https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf Noch was: Ich hoffe dein USB Kabel ist voll beschaltet. Inzwischen sind nämlich viele Kabel im Umlauf, mit denen man nur Akkus aufladen kann. Bei denen fehlen die Daten-Leitungen.
OMG schrieb: > Damit deine Ahnung etwas grösser wird: diese sogenannten Abblock- > Kondensatoren gehören direkt an die entprechenden Pins des > STM-Controllers (und natürlich direkt an Masse). Schaue dir ein > ReferenzDesign bzw. Layout von STM (siehe Nucleo-Boards) an und > verstehe wie das sein muss (nicht sollte sondern muss). Ja gebe ich dir völlig Recht, die 100nF gehören an die Entsprechenden Pins. Hätte ich irgendwie vergessen. Um ein neues Design komme ich da wohl nicht mehr drum rum. Ist halt die Frage ob das der Grund ist, dass ich gar nicht in den DFU-Mode komme.
Julian B. schrieb: > Die Frage ist jetzt, liegt der Fehler im Schaltplan oder was könnte man > machen um herauszufinden was das Problem ist? 1. VCAP1 und VCAP2 brauchen 2.2uF Kondensatoren. 2. Alle Abblockkondensatoren müssen möglichst klein sein (optimal 0402) und nur wenige mm vom jeweiligen VDD/VSS-Paar entfernt sein, sonst wirken sie nicht. Auch die Kondensatoren an VCAP1/VCAP2 betrifft das. 3. NRST sollte extern hochgezogen werden. 4. Der Resonator Q1 ist nicht stabil genug. Du musst einen Quarz mit mindestens 50ppm Stabilität (besser 30 oder 20) verwenden. Dazu Lastkondensatoren, die auf den Quarz abgestimmt sind. 5. Du solltest tunlichst die SWD-Pins (SWCLK, SWDIO, SWO) frei lassen und zusammen mit VDD/GND und NRST auf eine Stiftleiste führen, um Deinen Code debuggen zu können. Das ist das, was mir so auf Anhieb aufgefallen ist. fchk
Julian B. schrieb: > Ist halt die Frage ob das der Grund ist, dass ich gar nicht in den > DFU-Mode komme. Naja, wenn die Stabilisierung für die Core-Spannung schon nicht gut ist, wie soll da ein vernünftiger Betrieb möglich sein .... Frank K. schrieb: > VCAP1 und VCAP2 brauchen 2.2uF Kondensatoren.
Frank K. schrieb: > Du solltest tunlichst die SWD-Pins (SWCLK, SWDIO, SWO) frei lassen > und zusammen mit VDD/GND und NRST auf eine Stiftleiste führen, um Deinen > Code debuggen zu können. Ja, und so etwas würde ich auch sofort am Anfang machen (mit dem Debugger anfangen und hineinschauen) bevor ich versuche mit Bootloader etc. ein fertiges Programm zu laden und laufen zu lassen. Das geht sowieso in den meisten Fällen schief.
OMG schrieb: > Ja, und so etwas würde ich auch sofort am Anfang machen (mit > dem Debugger anfangen und hineinschauen) bevor ich versuche > mit Bootloader etc. ein fertiges Programm zu laden... Ach, zu allererst den Debugger noch vor jedem Programmladen? So etwas sehe ich anders. Den Debugger braucht man nämlich nicht derart dringend, wie es hier einige Leute darstellen. Aber wenigstens alle zum Programmieren relevanten Pins auf einen Steck zu führen, ist ein guter Ratschlag. Sowohl die für SWD als auch die für den Bootlader, einschließlich /Reset und die (je nach Chip variierenden) BOOTx Pins. Man kann die Dinger auch über einen der UART's programmieren, dann entfällt die Sorge, daß der Quarz falsch beschaltet ist. Und ob das Brennen nun 3 Sekunden oder 20 Sekunden dauert, ist auch egal, wenn man die Zeit einrechnet, die bei sowas hier in diesem Forum herumgepostet wird. W.S.
Stefan ⛄ F. schrieb: > Nein kein COM Port. Der Bootloader nutzt das DFU Protokoll. Das ist im Prinzip schnurz. Das OS im PC muß zuvörderst das Gerät abfragen und das muß antworten. Frank K. schrieb: > 2. Alle Abblockkondensatoren müssen möglichst klein sein (optimal 0402) Ach, das ist nicht so kritisch. Bei 0402 fällt vielen Leuten das Löten schwer und normale 0603 tun es auch. Und es ist kein wirkliches Problem, wenn da ein Zentimeter Abstand vom µC ist. Aber es ist immer ein Ärgernis, wenn jemand keine wirklich gute Massefläche macht, sondern nur die freien Stellen der LP mit einem Polygon zuklatscht. W.S.
Julian B. schrieb: > Ist halt die Frage ob das der Grund ist, dass ich gar nicht in den > DFU-Mode komme. Also einen Bug kenne ich, der das verursachen kann: Bei einigen älteren Chiprevisionen kann es passieren, dass der Oszillator zu langsam hochläuft, und der DFU-Bootloader nicht erkennt, dass er einen 8MHz-Clock hat. Er geht in irgendeinem State in einen Timeout und wirft das USB-Interface gar nicht an. Viel Spass beim lesen: https://www.st.com/content/ccc/resource/technical/document/application_note/b9/9b/16/3a/12/1e/40/0c/CD00167594.pdf/files/CD00167594.pdf/jcr:content/translations/en.CD00167594.pdf https://community.st.com/s/article/FAQ-DFU-mode-with-system-bootloader-is-not-working-while-USB-does AAAAABER erst mal auf die Bremse: Bevor man jetzt eine neue Leiterplatte macht oder irgendwas anderes: Erst mal mit JTAG drauf und schauen, ob man die Kiste programmiert bekommt und ob sie läuft. Es kann durchaus sein, dass dier Quarz gar nicht schwingt, USB nicht angelötet ist, Die Versorgung nicht passt, das Pinning nicht passt, die Kiste tot ist und vieles weitere mehr. Dass die 100n eine so große Rolle spielen, dass es GAR nichts geht, glaube ich ungeprüft nicht. Das macht üblicherweise andere Probleme, wie instabiles Verhalten.
Präziser ist das in der verlinkten AN2606 auf 28.1.2: Der Step "HSE detected" hat ein Timeout. Wenn der Quarz nicht schnell genug anschwingt, geht er in einen Reset. Man erkennt das am Reset-Loop. Der Timeout unterscheidet sich, bei älteren Chiprevisionen ist das irgendwas mit zig µs. Darum ist es bei der alten Schimmelgurke F4 mit USB und DFU immer etwas schwierig. In der Firma booten wir daher am Testadapter alle über JTAG. In der Applikation existiert das Problem ja nicht, es ist nur im Bootloader.
> Dass die 100n eine so große Rolle spielen, dass es GAR nichts geht, > glaube ich ungeprüft nicht. Das glaube ich auch nicht. Allerdings laesst sich das doch ganz schnell ausraeumen indem man einfach jeweils einen kleinen C direkt auf die Anschluesse loetet. Die liegen bei dem Gehaeuse doch nebeneinander. Das ist 0402 doch wirklich mal praktisch auch wenn ich denke das normalerweise 0603er ausreichen. Olaf
Stefan ⛄ F. schrieb: > Das Board sollte aber wenigstens als "unbekanntes" Gerät im > Gerätemanager auftauchen, zusammen mit einem "Palim" Geräusch (bei > Windows). Wenn es stattdessen "Pilam" macht, hast du eine > Kommunikationsstörung. > Nein, leider nicht, Windows reagiert überhaupt nicht, also auch kein Ton. > Linux ist in solchen Fällen übrigens recht gesprächig. Du kannst ein > Live System (z.B. Ubuntu) von USB Stick booten und direkt nach dem > Einstecken des USB Kabels "sudo dmesg" eingeben. Dann siehst du die > Kernel-Meldungen dazu. > Habs an meinem Raspberry Pi gehängt, leider auch nichts. > Wenn der PC das Anstecken des USB Kabel überhaupt nicht bemerkt, wurde > der Pull-Up Widerstand nicht aktiviert. Der Bootloader tut das aber. > Also könnte das ein Indiz dafür sein, dass der Mikrocontroller überhaupt > nicht arbeitet. Die Stromversorgung hast du geprüft. Prüfe auch die > Spannung am Reset Eingang und am Boot0 Pin. > NRST ist High und Boot0 ist High wenn man den S1 drückt. > Schwingt der Quarz-Oszillator, auch wirklich auf 8 MHz? > "An external clock multiple of 1 MHz (between 4 and 26 MHz) is > required for CAN and DFU bootloader execution after the selection > phase." > https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf > Kann ich leider nicht prüfen, aber ich kann mal den vom "gekauften Board" runter löten und bei meinem Board einbauen ist auch ein 8 MHz mit dem gleichen Footprint. > Noch was: Ich hoffe dein USB Kabel ist voll beschaltet. Inzwischen sind > nämlich viele Kabel im Umlauf, mit denen man nur Akkus aufladen kann. > Bei denen fehlen die Daten-Leitungen. Das ist mir klar, das Kabel funktioniert mit dem "gekauften Board", somit ist liegt es nicht am Kabel.
Frank K. schrieb: > 1. VCAP1 und VCAP2 brauchen 2.2uF Kondensatoren. Hatte jetzt auf die schnelle keine 2,2uF, habe mal für VCAP1 und VCAP2 jeweils 4,7uF zum Testen eingelötet. Leider keine Änderung. > 3. NRST sollte extern hochgezogen werden. Das wäre noch ein Versuch wert, werde ich später testen. > 4. Der Resonator Q1 ist nicht stabil genug. Du musst einen Quarz mit > mindestens 50ppm Stabilität (besser 30 oder 20) verwenden. Dazu > Lastkondensatoren, die auf den Quarz abgestimmt sind. Möglich, werd demnächst mal einen von einem funktionierenden Board auslösen und bei meinem Board einlöten. > 5. Du solltest tunlichst die SWD-Pins (SWCLK, SWDIO, SWO) frei lassen > und zusammen mit VDD/GND und NRST auf eine Stiftleiste führen, um Deinen > Code debuggen zu können. Ist eigentlich bei Flightcontroller nicht üblich, den es wird ja nur das fertige hex-File von iNav oder Betaflight aufgespielt. Eigenen Code habe ich nicht vor zu verwenden. Die Pinbelegung ist deshalb nach diesem Config File erstellt worden: https://github.com/iNavFlight/inav/blob/362f5c5dc159fe3b100bf8a9022e294b6e5d32ed/src/main/target/MATEKF405SE/target.h
Julian B. schrieb: > Ist eigentlich bei Flightcontroller nicht üblich, den es wird ja nur das > fertige hex-File von iNav oder Betaflight aufgespielt. Entweder man will einen Fehler finden, dann arbeitet man mit SWCLK und SWDIO und lässt damit (mit einem Debugger) testhalber ein kleines Progrämmchen laufen, oder man gibt sich mit dem aktuellen Zustand zufrieden, dann ist ja auch alles in Ordnung.
W.S. schrieb: > Das ist im Prinzip schnurz. Wenn der Kollege vergeblich einen COM Port im Gerätemanager sucht, ist das gar nicht Schnurz, weil er an dieser Stelle nicht weiter kommt. Also: Da ist kein COM Port zu erwarten. DFU geht ohne COM-Port.
OMG schrieb: > Entweder man will einen Fehler finden, dann arbeitet man mit > SWCLK und SWDIO und lässt damit (mit einem Debugger) testhalber > ein kleines Progrämmchen laufen, oder man gibt sich mit dem > aktuellen Zustand zufrieden, dann ist ja auch alles in Ordnung. Ja das werde ich wohl machen müssen. An SWCLK und SWDIO hängt aktuell jeweils eine LED. Die grüne LED an SWDIO leuchtet auch nach ner Weile, wenn das Board eine weile mit Spannung versorgt wird.
Statt sich bei sowas den Windows Geräte-Manager anzutun empfehle ich https://www.uwe-sieber.de/usbtreeview.html
Stefan ⛄ F. schrieb: > Wenn der Kollege vergeblich einen COM Port im Gerätemanager sucht, ist > das gar nicht Schnurz, weil er an dieser Stelle nicht weiter kommt. Und wenn man nur drauf achtet, daß aus dem Brüllwürfel ein "Palim" und kein "Pilam" kommt, dann sucht man damit auch an der falschen Stelle. Bloß mal zum Vergleich. Dennoch ist es so, daß vor allen Verwendungen das Enumerieren kommt, also das Abfragen des Gerätes durch den Host. Ganz egal, was für ein Protokoll da später laufen soll. Aber hier rührt sich offenbar rein garnix. Und weil der TO sich ein systematisches Suchen nach der Ursache nicht zutraut, versucht er es jetzt mit dem Umlöten des Quarzes. Frei nach dem Motto: "wenn der Transistor nicht paßt, nehmen wir einen größeren Hammer". Mir kommt da jetzt ein ganz böser Gedanke: ist es denkbar, daß der angebliche STM32 nur ein übler Fake ist, den ein windiger Chinese dem TO angedreht hat? Schön "STM32" und "ARM" gravieren können die ja inzwischen, egal was überhaupt drin ist. W.S.
W.S. schrieb: > daß der angebliche STM32 nur ein übler Fake ist Ich dachte davon sind nur STM32F103 betroffen. Nicht?
Stefan ⛄ F. schrieb: > Ich dachte davon sind nur STM32F103 betroffen. Nicht? Das hängt nur davon ab, was da jemand auf das Gehäuse lasert. Ich habe hier auch noch ein paar AD820, die keine sind. Man kann es also auch nicht an der Bauform festmachen. Irgendwo bei YT gibt es auch ein Video, wo jemand einige angebliche SSD zeigt, die nur ein Gehäuse mit ein paar dort hineingepackten Speicher-Sticks sind. Also: die Betrüger werden sowohl technisch immer besser, als auch dreister. W.S.
W.S. schrieb: > Mir kommt da jetzt ein ganz böser Gedanke: ist es denkbar, daß der > angebliche STM32 nur ein übler Fake ist, den ein windiger Chinese dem TO > angedreht hat? Schön "STM32" und "ARM" gravieren können die ja > inzwischen, egal was überhaupt drin ist. Das könnte natürlich auch möglich sein, als ich den bestellt habe Ende letzten Jahres, da waren die fast überall ausverkauft. Da musste ich hier drauf zurück greifen: https://a.aliexpress.com/_uzq5YI Mittlerweile gibt’s aber wieder einige bei Seriösen Händlern.
Wird USB Dp denn durch den internal pullup des STM auf VDD gezogen? Was mir noch aufgefallen ist, wahrscheinlich aber nicht mit dem Problem zusammenhängt: Ist da eine Lötbrücke zwischen Pin 21 und 22? Kannst du die Gerber Files der Platine zur Verfügung stellen?
Alexander S. schrieb: > Wird USB Dp denn durch den internal pullup des STM auf VDD gezogen? Nein DP bleibt low > Was mir noch aufgefallen ist, wahrscheinlich aber nicht mit dem Problem > zusammenhängt: Ist da eine Lötbrücke zwischen Pin 21 und 22? Das hab ich recht schnell am Anfang schon behoben Hab jetzt auch noch VCAP1 und VCAP2 gegen 2,2uF ausgetauscht. Auch NRST auf GND ziehen hat nichts gebracht Fürs debuggen muss ich mir erst noch ein Debugger zulegen, hab da an einen ST-LINK/V2 gedacht mit der STM32CubeIDE
:
Bearbeitet durch User
Julian B. schrieb: > Nein DP bleibt low Dann führt der Mikrocontroller kein Programm (bzw. den Bootloader) aus. Oder es ist eine schlechte Fälschung ohne USB Support im Bootloader. Julian B. schrieb: > Fürs debuggen muss ich mir erst noch ein Debugger zulegen, hab da an > einen ST-LINK/V2 gedacht mit der STM32CubeIDE OK. Du könntest noch den seriellen (UART) Bootloader versuchen.
Julian B. schrieb: > Auch NRST auf GND ziehen hat nichts gebracht Der muss über einen 10k oder so auf VDD gezogen werden. Wenn der auf GND ist, ist der Prozessor im Dauerreset. > Fürs debuggen muss ich mir erst noch ein Debugger zulegen, hab da an > einen ST-LINK/V2 gedacht mit der STM32CubeIDE Oder den V3, der hat High Speed USB. Kabel musst Du Dir selber dranlöten. https://www.reichelt.de/in-circuit-debugger-programmierer-fuer-stm32-stlink-v3mods-p277187.html fchk PS: Ich meine, dass man das System Flash, wo der Bootloader drin ist, auch löschen und anderweitig benutzen kann. Das ist kein ROM. Nur mal so als Idee.
:
Bearbeitet durch User
Hm, hattest du nur vusb und gnd verbunden als du Dp gemessen hattest? (ggfs. zieht dein Rechner ansonsten den pin runter, kenne den usb standard da nicht gut genug) nrst und boot0 sollten für diesen Test die ganze Zeit high sein, ggfs. brückst du dafür boot0 direkt auf vdd. Und um eine andere mögliche Fehlerquelle auszuschließen: Hast du mal versucht an allen Beinchen des Mikrocontrollers mit einer spitzen Pinzette o.ä. zu wackeln, sind alle fest verbunden?
Frank K. schrieb: > Der muss über einen 10k oder so auf VDD gezogen werden. Wenn der auf GND > ist, ist der Prozessor im Dauerreset. Ja, natürlich mein Fehler. Alexander S. schrieb: > Hm, hattest du nur vusb und gnd verbunden als du Dp gemessen hattest? > (ggfs. zieht dein Rechner ansonsten den pin runter, kenne den usb > standard da nicht gut genug) DP ist ohne die Verbindung zum Rechner bei 2,5V >nrst und boot0 sollten für diesen Test die > ganze Zeit high sein, ggfs. brückst du dafür boot0 direkt auf vdd. nrst und boot0 hab ich direkt auf 3,3V gelegt. > Und um eine andere mögliche Fehlerquelle auszuschließen: Hast du mal > versucht an allen Beinchen des Mikrocontrollers mit einer spitzen > Pinzette o.ä. zu wackeln, sind alle fest verbunden? Ja, hab nochmal alles nachgelötet. Und dann hab ich noch folgende Anpassungen gemacht: 2x 22nF an den Quarz-Oszillator und R32 ausgelotet (der bewirkte, dass UART4-RX high war). Wenn man dann den S1 gedrückt hält (also boot0 auf 3,3V zieht), PA9 und PA10 auf GND zieht, während dem Einstecken des USB-Kabels dann geht er in den DFU-Mode!!! 😃 Allerdings, läuft er nicht ganz stabil. Das fashen musste ich drei mal wiederholen bis er es gepackt hat, hat bei flashen immer die Verbindung verloren. Nun ist Software drauf und die LEDs blicken, allerdings läuft es nicht stabil und er verliert öfters die Verbindung bzw. startet neu oder hängt sich auf. So ganz genau weiß ich das nicht. Ob das jetzt an einem instabilen Oszillator, den 22pF am Oszillator, den falsch platzierten Abblock-Kondensatoren, oder an etwas ganz andrem liegt gilt nun rauszufinden.
Im gründe genommen ist es jetzt so, dass es spuradisch funktioniert, wenn man ihn mit Spannung versorgt. Mal startet der STM32 mal nicht.
Julian B. schrieb: > DP ist ohne die Verbindung zum Rechner bei 2,5V Ich hätte 3,3V erwartet. Vergleiche das mal mit einem fertigen Entwicklungsboard (Nucleo64 oder so).
Stefan ⛄ F. schrieb: > Habe gerade nachgemessen: Mein Nucleo L073 Board hat am offenen DP Pin > (PA12) exakt 3,3V. Hab auch nochmal nachgemessen. Wenn er nicht anläuft lag grad die Spannung am DP bei 1,2V und wenn er anläuft lag sie bei 3,2V (nicht am PC sondern per USB an der Powerbank). Die 22pF Lastkondensatoren am Oszillator Q1 hab ich wieder entfernt. Im Datenblatt von Q1 steht: „ …with built-in load capacitors … the elimination of the need for an external load capacitor.“ https://www.murata.com/en-sg/api/pdfdownloadapi?cate=&partno=CSTCE8M00G52-R0 Am Verhalten hat sich dadurch nichts geändert. Wartet man eine Weile bevor man das Board seit dem letzten Mal mit Strom versorgt hat, dann startet der STM32 meistens, aber läuft dann maximal nur 1-2 Minuten stabil. Die LEDs blinken dann und man kann sich kurz mit USB an den Flightcontol Programm verbinden (INAV Configurator). Dann bricht die USB Verbindung ab und die LEDs leuchten dauerhaft.
:
Bearbeitet durch User
Der AMS1117-3.3 ist übrigens auch 'ne Krücke. Eigentlich möchten alle LDOs der 1117 Serie am Ausgang einen Elektrolytkondensator (im Datenblatt zum AMS1117 wird Tantal genannt) und keinen Keramikkondensator (auf Deinem Board sieht es so aus als ob Du einen normalen MLCC genommen hättest). Der ESR darf tatsächlich nicht zu klein(!) sein. Zudem ist eine Mindestlast von 10mA notwendig damit das Ding richtig regelt. Ich würde da lieber einen MCP1754 hernehmen, wenn Deine Schaltung nicht mehr als 150mA benötigt ist das die bessere Wahl.
:
Bearbeitet durch User
Julian B. schrieb: > aber läuft dann maximal nur 1-2 Minuten stabil Du kannst den Systemtakt an einem in ausgeben lassen, irgendein RCC Register stellt das ein. Mach das mal und kontrolliere, ob die Frequenz dort stabil ist.
Warum nehmen eigentlich soviele Leute immer noch diese Quarze mit Kondesatoren anstatt einens fertigen Oszillators?
Markus M. schrieb: > Warum nehmen eigentlich soviele Leute immer noch diese Quarze mit > Kondesatoren anstatt einens fertigen Oszillators? Weil der Oszillator zumeist bereits (bis auf den Quarz) im Chip vorhanden ist und zugleich die Anpassung zum chipinternen Taktsystem damit erledigt ist. W.S.
Markus M. schrieb: > Der AMS1117-3.3 ist übrigens auch 'ne Krücke. > Und der NCP1117ST33T3G ist der besser? > Eigentlich möchten alle LDOs der 1117 Serie am Ausgang einen > Elektrolytkondensator (im Datenblatt zum AMS1117 wird Tantal genannt) > und keinen Keramikkondensator (auf Deinem Board sieht es so aus als ob > Du einen normalen MLCC genommen hättest). Der ESR darf tatsächlich nicht > zu klein(!) sein. Ja stimmt hab da Keramikkondensatoren drin -_- > > Zudem ist eine Mindestlast von 10mA notwendig damit das Ding richtig > regelt. Spätestens wenn der STM32 anläuft ist die mindestest Last da, davor eventuell noch nicht. > > Ich würde da lieber einen MCP1754 hernehmen, wenn Deine Schaltung nicht > mehr als 150mA benötigt ist das die bessere Wahl. Hmm die 150mA werden vermutlich zu knapp, hab noch ne Menge anderer Chips drauf die auch 3,3V benötigen (Baro, IMU, Compass, Sensoren, GPS, … was man halt so braucht, sind aber noch nicht alle aufgelötet). Eventuell Versuch ich den LDO auszulöten und die 3,3V mit dem Labornetzteil einzuschleifen um festzustellen, ob es dann stabil läuft.
:
Bearbeitet durch User
Julian B. schrieb: > Eventuell Versuch ich den LDO auszulöten und die 3,3V mit dem > Labornetzteil einzuschleifen um festzustellen, ob es dann stabil läuft. Die meisten LDO brauchst du dabei gar nicht zu entfernen. Sie vertragen Fremd-Speisung von hinten.
Julian B. schrieb: > Markus M. schrieb: >> Der AMS1117-3.3 ist übrigens auch 'ne Krücke. >> > Und der NCP1117ST33T3G ist der besser? Nein, da ist es sogar ganz klar definiert: "Frequency compensation for the regulator is provided by capacitor Cout and its use is mandatory to ensure output stability. A minimum capacitance value of 4.7 µF with an equivalent series resistance (ESR) that is within the limits of 33 mOhm (typ) to 2.2 Ohm is required." >> Ich würde da lieber einen MCP1754 hernehmen, wenn Deine Schaltung nicht >> mehr als 150mA benötigt ist das die bessere Wahl. > Hmm die 150mA werden vermutlich zu knapp, hab noch ne Menge anderer > Chips drauf die auch 3,3V benötigen (Baro, IMU, Compass, Sensoren, GPS, > … was man halt so braucht, sind aber noch nicht alle aufgelötet). Okay, dann musst Du mal schauen mit der parametrischen Suche z.B. bei Mouser. Wie hoch ist denn die max. Eingangsspannung für Deinen FC? Die fertigen verwenden ein switching BEC um von der Akkuspannung auf 5V zu wandeln und dann einen LDO um auf 3.3V zu kommen. Ein switching BEC willst Du ja sicher nicht auch noch selbst bauen? Wenn die Eingangsspannung für den LDO dann max. 5V ist musst Du schauen welcher LDO die notwendige Leistung bringt und dabei nicht zu groß ist. Warum baust Du eigentlich den FC selbst? Es ist ja nicht so dass es nicht genügend Auswahl gäbe ;-) Also interessant ist es ja, aber will man nicht eher mit dem Copter fliegen? Da ist ja noch genug zu basteln und konfigurieren wenn man noch GPS etc. anbinden möchte.
Markus M. schrieb: > Okay, dann musst Du mal schauen mit der parametrischen Suche z.B. bei > Mouser. Wie hoch ist denn die max. Eingangsspannung für Deinen FC? Die > fertigen verwenden ein switching BEC um von der Akkuspannung auf 5V zu > wandeln und dann einen LDO um auf 3.3V zu kommen. Ein switching BEC > willst Du ja sicher nicht auch noch selbst bauen? Hab noch ein paar MCP1700T-3302E daheim gefunden, der könnte auch gehen. Die Eingangspannung des LDOs kommt entweder über USB oder über einen Buck Converter beides mal 5V. > Warum baust Du eigentlich den FC selbst? Es ist ja nicht so dass es > nicht genügend Auswahl gäbe ;-) Also interessant ist es ja, aber will > man nicht eher mit dem Copter fliegen? Da ist ja noch genug zu basteln > und konfigurieren wenn man noch GPS etc. anbinden möchte. Es soll ein 18650 1S 3 Zoll Mini Quad komplett als PCB werden, mit gekauften PCBs wird es da zu schwer, da auch noch ein spezieller Raspberry Pi drauf kommt für die Video Übertragung. Deshalb und weil mich es schon reitzt eine eigene Steuerung zu machen.
Stefan ⛄ F. schrieb: > Die meisten LDO brauchst du dabei gar nicht zu entfernen. Sie vertragen > Fremd-Speisung von hinten. Hab ihn jetzt trotzdem mal entfernt und mein Labornetzteil dran angeschlossen. Leider trotzdem noch das gleiche Problem. Ich glaube der CSTCE8M00G52-R0 Schwingt nicht stabil genug. Laut Datenblatt hat der +/- 0,5% Genauigkeit was 5000ppm entspricht. Da ich gern über JLCPCB/LCSC bestelle, würde ich es gerne folgenden Oszillator verwenden: X322512MSB4SI, https://lcsc.com/product-detail/Crystals_Yangxing-Tech-X322512MSB4SI_C9002.html Als Load Capacitors würde ich 32pF vorsehen. Cl=2*(CLOAD_CRYSTAL - CAPARSTIC) Cl=2*(20p-4p) Soll man dafür auch einen Feed Resistor einsetzen und wie berechnet man den?
Angehängte Dateien:
-
usb.PNG
4,3 KB
Also meine USB Buchse funktioniert, suche den Unterschied ;). Tipp: Es ist nicht U4, obwohl ich den bei dir ebenfalls vermisse. Soll ja länger als drei Wochen halten. Häng mal D+ über 1,5KOhm an 3,3V und schon sollte das klappen. Danach BOOT 0 auf GND ziehen und USB Kabel einstöpseln. VG Paul
Julian B. schrieb: > Ich glaube der CSTCE8M00G52-R0 Schwingt nicht stabil genug. Laut > Datenblatt hat der +/- 0,5% Genauigkeit was 5000ppm entspricht. Das ist viel zu viel. > Da ich gern über JLCPCB/LCSC bestelle, würde ich es gerne folgenden > Oszillator verwenden: X322512MSB4SI, Das ist kein Oszillator, sondern ein Quarz. Ein Quarz braucht eine externe Oszillatorschaltung, um zu schwingen, der tut das nicht alleine. DAS hier ist ein Oszillator: https://lcsc.com/product-detail/Oscillators_Yangxing-Tech-OT32258MJBA4SL_C717687.html Da legst Du 3.3V und GND an, und dann kommt da ein 8MHz Rechteck raus. Quasi idiotensicher, also passend für Dich. Das Ausgangssignal musst Du nur noch auf OSCI vom STM32 geben. Ich mache immer noch einen kleinen Serienwiderstand von 10...22 Ohm dazwischen, um Störungen zu vermeiden. Dazu einmal 100n zwischen GND und VCC, und den Enable-Pin per 0 Ohm Brücke entweder auf GND oder auf VCC legen (das ist jetzt nicht ganz so klar im Datenblatt. Meistens ist High=Aktiv und low=aus, aber das kann auch anders sein. Also SMD-Jumper vorsehen. fchk
Paul schrieb: > Also meine USB Buchse funktioniert, suche den Unterschied ;). > > Tipp: Es ist nicht U4, obwohl ich den bei dir ebenfalls vermisse. Soll > ja länger als drei Wochen halten. > Häng mal D+ über 1,5KOhm an 3,3V und schon sollte das klappen. Danach > BOOT 0 auf GND ziehen und USB Kabel einstöpseln. > > VG Paul Fürs die nächste Version habe ich einen USBLC6-2SC6 vorgesehen.
Angehängte Dateien:
Nun hab ich das aktuelle Design stabil zum Laufen gebracht. Folgendes habe ich zu dem Schaltplan im ersten Post noch zusätzlich anpassen müssen damit es stabil funktioniert: NRST braucht keinen PullUp (siehe Bild), NRST hat am STM32F4 einen internen PullUp "RPU" (auf Seite 119 im Datenblatt nachzulesen). Dafür an NRST einen 100nF. Boot1 (PB2) muss mit 10k auf GND gezogen werden, damit der DFU zuverlässig startet. Den AMS1117-3.3 habe ich durch einen MCP1700-3302 mit zwei 1uF X7R ersetzt, da der AMS1117 die 3,3V nicht stabil halten konnte. Und wie im Datenblatt vom STM32F4 gefordert einen 4,7uF Kondensator an einen VDD Pin. Den Q1 CSTCE8M00G52-R0 konnte ich drin lassen. Und nun läufts stabil.
:
Bearbeitet durch User
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.