Ich habe ein (für mich) etwas merkwürdiges Problem: Ich möchte mir ein eigenes Dev-Board auf Basis des auf Ebay ( http://www.ebay.de/itm/STM32F103C8T6-STM32-Minimum-System-Development-Board-Module-For-Arduino-TE435-/272283008473?hash=item3f6554fdd9:g:GTAAAOSwMNxXazXE ) massenhaft verkauften BluePill Boards STM32F103C8T6 entwickeln. Dieses Board möchte ich NICHT mittels ST-Link flashen, sondern ich möchten den integrierten seriellen Bootloaders des STM32 nutzen. Nun ist das mit der BluePill eine ziemliche Frickelei: Boot0 Jumper auf 1 stecken, Reset druecken, mittels STM32flash Programm flashen, Boot0 Jumper zurück auf 0, Reset drücken. Das wollte ich eleganter machen und dachte mir: Okay, das kann auch der billigste / kleinste ATtiny, ich drücke eine Taste und lasse diese Abfolge generieren, eine LED zeigt mir an, dass ich Bootloader aktiviert habe, Programm übertragen, Taste noch einmal drücken fertig. Eigentlich ist das Programm für den Tiny ein Witz (so dachte ich jedenfalls), Pustekuchen !!!! Die Abfolge mit dem Tiny zu generieren ist einfach und ich habe das auch schon oszilloskopiert. Einzig es funktioniert nicht !!!! Wenn der Tiny (wie im Schaltbildausschnitt) den BOOT0 aktiviert, und ich den Reset auf dem BluePill drücke, bin ich im Bootloadermodus und ich kann ein Programm flashen. Lasse ich den Resetimpuls mittels des Tiny generieren funktioniert das nicht ! Dann habe ich mir das Schaltbild der Bluepill angesehen und festgestellt, es ist ein Kondensator am Resetpin gegen Masse verschaltet: 100nF ! Okay, dachte ich mir, den entfernst du... geht aber dennoch nicht. Resetimpuls bis zu einer Sekunde verlängert ... geht nicht. Resetimpuls invertiert ausgegeben und über einen Schalttransistor (BC549 und auch mittels eines FET BS170) versucht den Resetpin auf 0 zu ziehen ... geht nicht !!!! Ich guck mir das auf dem Speicherscope an. Resetleitung wird satt auf 0 und auch satt wieder auf 3,3V gesetzt. Geht aber dennoch nicht ! Kann sich das jemand erklären ? Dann, mit dem "Spielen" fällt mir etwas auf (serieller Chip ist ein CH340G): Wenn ich ein serielles Programm geflasht habe, ein Terminalprogramm offen habe (DTR und RTS sind nicht aufgelegt) ... und ich aktiviere am Tiny den Bootloadermodus... ich beendet das Terminalprogramm.... dann ist die Bluepill tatsächlich im Bootloadermodus und ich kann den STM32 flashen. Ansonsten (ohne Aufruf des Terminalprogramms) muß ich, nachdem der Tiny Boot0 auf 1 gelegt hat, den Reset von Hand über den Resettaster der Bluepill aktivieren. Ich habe keine Ahnung, woran das liegt ! (in meinen Versuchen habe ich sogar versucht, den Reset mittels eines Relais zu aktivieren, das klappt dann witzigerweise). Die Transistorstufe, die den Reset betätigt hat einen Basisvorwiderstand von 1 kOhm. Kollektor an Resetleitung, Emitter an Masse. Bei Verwendung des FET's am Gate 1 MOhm gegen Masse, Drain an der Resetleitung, Source an Masse.
Angehängte Dateien:
-
bluepill_circuit.gif
4,1 KB -
bluepill_circuit_transistor.gif
4,2 KB
Sollte eigentlich gehen. Ist denn auch GND verbunden? Wenn ja: prüfe nochmal genau, ob du den Transistor richtig angeschlossen hast. Den 100nF Kondensator würde ich nicht entfernen, er sorgt dafür, dass dein Modul mit etwas Verzögerung nach Anlegen der Versorgungsspannung aus dem Reset geholt wird. Besser wäre ein ca. 47R Serienwiderstand in der Reset-Leitung (zwischen Collector des Transistors und RESET).
Joe F. schrieb: > Ist denn auch GND verbunden? ist es natürlich (sonst würde bspw. das Ding mittels Relais ja bspw. nicht funktionieren). Joe F. schrieb: > er sorgt dafür, dass > dein Modul mit etwas Verzögerung nach Anlegen der Versorgungsspannung > aus dem Reset geholt wird. weiß ich ! Joe F. schrieb: > Besser wäre ein ca. 47R Serienwiderstand Bedämpfungswiderstände habe ich bis 100 Ohm versucht... By the way: Ich habe versucht mittels eigenem 3,3V Regler (LM317 und EXAKT eingestellt) und dem 3,3V Regler auf der BluePill das ganze zu betreiben. Gleicher Effekt. Allerdings habe ich jetzt noch eine Merkwürdigkeit: Wenn im STM32 ein Programm arbeitet, das sich NICHT der seriellen Schnittstelle bedient funktioniert es. Läuft ein Programm mit permanentem RS-232 Datentransfer dann habe ich den Eingangs beschriebenen Effekt.
Angehängte Dateien:
-
2017-03-13_193821.png
13 KB
Ralph S. schrieb: > Nun ist das mit der BluePill eine ziemliche Frickelei: Boot0 Jumper auf > 1 stecken, Reset druecken, mittels STM32flash Programm flashen, Boot0 > Jumper zurück auf 0, Reset drücken. Wieso ? Einfach "Jump to the user program" checken - kein umstecken nötig. Wenn alles Fehlerfrei läuft, Jumper zurück, BluePill einbauen. Was soll daran umständlich sein ?
Ist denn der RX-Pin des STM32 sauber auf 3.3V während Reset anliegt und kurz danach? Nicht, dass die Gegenseite beim permanenten Datenverkehr noch sendet (die bekommt den Reset ja nur indirekt mit). Echte RS232-Pegel sind im Ruhezustand bei -5V oder noch schlimmer. Wenn davon etwas zum BOOT- oder NRST-Pin durchsickert könnte u.U. alles mögliche passieren. So eine Reset/Boot-Mimik mit Transistor funktioniert hier jeden Tag 97 mal. Und 3 mal nicht. Ich ignoriere das einfach ;)
RS232 wird nur mit dem CH340 realisiert. Einen Levelshifter auf +- Spannung ist nicht im System. Der 340 wird mit 3,3V betrieben. Wie es aussieht empfängt der STM32 "irgendwas" über den UART und deshalb dürfte keine Übertragung zustande. Im Moment bin ich dabei, das stm32flash zu modifizieren, dass vor Datenübertragung die Eingangspuffer leer sind.
OT und daher leider keine konkrete Hilfe, aber: Ich bin jeden Tag, an dem ich meinen J-Link EDU benutze, froh, daß ich vor vielen Jahren diese 50 oder 60 Euro ausgegeben habe.
Lutz schrieb: > OT und daher leider keine konkrete Hilfe, aber: Ich bin jeden Tag, an > dem ich meinen J-Link EDU benutze, froh, daß ich vor vielen Jahren diese > 50 oder 60 Euro ausgegeben habe. Das ist ja nicht das Problem, einen ST-Link v2 und einen Seeger hab ich ja auch. Es dreht sich darum ein sehr kostengünstiges zuverlässiges Board zu machen, bei dem ich unterm Strich nur ein USB Kabel einstecke. Hm, wie es ausschaut ist ein Nucleo Board nicht wirklich zu toppen.
Kenn ich ! STM32duino probagiert IMMER einen USB-Bootloader (genau den ich NICHT will) !
Jeder wie er mag; ich mag den integrierten seriellen Bootloader, aber mit USB-Stecker, FT232R und Optokopplern zwischen USB und STM32. Der FT232R wird per USB vom PC versorgt, der STM32 von irgendwo. Es kann keine Probleme mit rückwärts einspeisen und Masseschleifen geben. Ein- und ausstecken im Betrieb stört weder den STM32 noch den PC. Als totalen Luxus spendiere ich einen 4060, der aus einem seriellen "Break" die BOOT- und NRST-Signale generiert. Keine Jumper, kein Reset-Taster (und damit auch kaum größer). Der integrierte Bootloader hat den großen Vorteil, dass das PC-Bootloader-Programm den Chip und das Flash nicht kennen muss. Es funktioniert sofort auch mit den neuesten Chips und altem Programm.
Ralph S. schrieb: > Das wollte ich eleganter machen... O ja, sehe ich, sehr elegant. Zunächst eines: wenn ich mich recht erinnere, dann sollten BOOT0 (Pin 44) und BOOT1 (Pin 20) für den Normalbetrieb auf low liegen - also keine Hochzieher dran, sondern 10k..22k gegen Masse. Dann verbindet man nicht nur RX1 und TX1 mit dem PC über ne Serielle mit TTL-Pegeln, sondern auch BOOT0 und Reset, beide letztere eventuell mit 100 Ohm in der Leitung. Ich benutze einen simplen USB-Adapter mit nem FTDI drin. Das war's. Mehr braucht man nicht, kein Relais, kein ATtiny. Bei mir funktioniert das ganz prächtig und bei vielen anderen auch und es ist überhaupt keine Frickelei dabei. Stecker ran, dem Brennprogramm gesagt, daß es nach dem Brennen die App starten soll und gut ist es. Also sollte das auch bei dir funktionieren. W.S.
Angehängte Dateien:
-
bluepill02_kl.jpg
130 KB -
bluepill01_kl.jpg
160 KB
W.S. schrieb: > Zunächst eines: wenn ich mich recht erinnere, dann sollten BOOT0 (Pin > 44) und BOOT1 (Pin 20) für den Normalbetrieb auf low liegen - also keine > Hochzieher dran, sondern 10k..22k gegen Masse. ... mit Widerständen habe ich das zuerst versucht gehabt. Als das nicht funktioniert hatte war ich sogar schon (in meiner Verzweiflung) soweit, das mit komplementären Transistoren zu machen (satt auf 1 und satt auf 0 schalten)... hatte alles nichts genutzt. Mittlerweile jedoch weiß ich weshalb: es lag nicht an der Hardware ! W.S. schrieb: > Dann verbindet man nicht nur RX1 und TX1 mit dem PC über ne Serielle mit > TTL-Pegeln, sondern auch BOOT0 und Reset, beide letztere eventuell mit > 100 Ohm in der Leitung. Manchmal (aber nur manchmal) schüttle ich den Kopf, was alles angenommen wird. Würde ich das nicht wissen müsste ich die Finger von MCUs lassen. BTW: TTL-Pegel mag der F103 nicht (auch wenn der auf vielen Pins 5V tolerant ist), ich hab einen CH340G und den hardwareseitig auf 3,3V konfiguriert (weil der F030 TTL-Pegel nicht mag). BTW: 100 Ohm als Bedämpfung finde ich schon etwas hoch, bei 3,3V Pegeln verwende ich zwischen 47 und 68 Ohm. Es ging auch nicht darum den F103 grundsätzlich zum Laufen zu bekommen (denn das geht). Es ging darum, ein ultrabilliges "Board" zu entwickeln, auf dem eine BluePill eingesetzt wird und mit dem ich den F103 Flashen kann, OHNE dass ich einen ST-Link benötige und OHNE dass ich auf dem Board (ausser vllt. Reset) betätigen muß und dennoch ein Upload klappt. Der Fehler bei mir lag schlicht im Uploadprogramm und zwar immer dann, wenn auf dem F103 ein Programm läuft, das kontinuierlich Daten über die serielle Schnittstelle gesendet werden, auf dem der F103 auch geflasht werden soll. Die Lösung war, das (Linux)Programm stm32flash dahingehend zu modifizieren, dass vor dem Setzen des Bootmodus einen Reset ausführt, den Reset hält, den Ausgangs- und Eingangspuffer der seriellen Schnittstelle (PC) leert, weil dann ein Zeichen, das NICHT vom Flashprogramm stammt als erstes gesendet werden würde. Erst danach wird der Bootloadermodus (mittels DTR) gesetzt. Das klappt mittlerweile und ich konnte die Bluepill auf eine Platine mit R3 (Arduino) Formfaktor setzen, die sich jetzt ausschließelich über den CH340G flashen lässt und dieser vom Anwenderprogramm im STM auch als serielle Schnittstelle nutzen lässt. Frei nach Arduino: USB-Kabel rein und loslegen ! Meine Auszubildenden arbeiten mittlerweile schon damit.
PS: im Moment bin ich am Routen der Schaltung, damit diese nicht wie hier der Prototyp gefädelt werden muss.
Ralph S. schrieb: > Die Lösung war, das (Linux)Programm stm32flash dahingehend zu > modifizieren, dass vor dem Setzen des Bootmodus einen Reset ausführt, > den Reset hält, den Ausgangs- und Eingangspuffer der seriellen > Schnittstelle (PC) leert, weil dann ein Zeichen, das NICHT vom > Flashprogramm stammt als erstes gesendet werden würde. Erst danach wird > der Bootloadermodus (mittels DTR) gesetzt. Ja sag mal! Also bei Windows wird dann, wenn man eine serielle Schnittstelle öffnet, selbige geleert dem Programm übergeben. Da kommen keine fremden Überhang-Daten von anderen Programmen hinein oder heraus. Ist das bei Linux denn ANDERS? Sprudeln da fremde Daten im Nachgang aus der Seriellen heraus, obwohl diese vom vorherigen Programm bereits geschlossen wurde? (Ohne dies könnte man sie ja garnicht selbst öffnen) Und soweit ich das im RefMan gelesen habe, sind alle Pins der STM32F102xxx 5V-tolerant, es sei denn, man setzt sie in den Analog-Modus. Mit seriell-TTL meine ich natürlich, daß die Signale eben NICHT in +/- 12V und negativer Logik vom PC ankommen, sondern eben im TTL-Bereich, wo für hi schon 2.4V ausreichen. Bei meinem FTDI kommt als hi Pegel so etwa 3.3V heraus. W.S.
W.S. schrieb: > Ja sag mal! Also bei Windows wird dann, wenn man eine serielle > Schnittstelle öffnet, selbige geleert dem Programm übergeben. Da kommen > keine fremden Überhang-Daten von anderen Programmen hinein oder heraus. > Ist das bei Linux denn ANDERS? Bei Linux wird die serielle Schnittstelle erstmal wie eine Datei behandelt, die man öffnen, lesen, beschreiben und schließen kann. Das geht auch prinzipiell von mehreren Programmen gleichzeitig. Man kann eine Schnittstelle in der Konsole mit Minicom, Picocom oder was auch immer offen haben und gleichzeitig z.B. mit einem Pythonskript Daten auf diese Schnittstelle senden. Die gesendeten Daten tauchen dann im Minicom nicht auf, sehr wohl aber eine etwaige Antwort (wenn man sie nicht vorher mit dem Skript ausgelesen hat). Natürlich gibt es auch auf Seite des OS noch FIFOs um Lese- und Schreibzugriffe zu puffern. Die kann man manuell leeren, muss man aber nicht zwingend, weil für das leeren der FIFOs entsprechende Timeouts konfiguriert sind die nach dem schließen der Schnittstelle (d.h. der Datei) dafūr sorgen das die geleert werden. W.S. schrieb: > Sprudeln da fremde Daten im Nachgang aus der Seriellen heraus, obwohl > diese vom vorherigen Programm bereits geschlossen wurde? Ich vermute mal stark, dass die aus dem CH340 heraussprudeln, da der ja auch noch entsprechende Puffer hat. Natürlich sollten diese bei schließen der Schnittstelle auch geleert werden aber ob das tatsächlich der Fall ist würde ich hier mal bezweifeln. Das mag durchaus am Treiber liegen und es mag durchaus sein, dass der die Puffer nur leert wenn man es explizit fordert. Besonders viel Liebe hat der CH340 bisher von den Kernelentwicklern nicht erfahren, wobei das durchaus daran liegen könnte, dass es sich laut den BSD-Jungs um "the worst usb serial chip in the world" handelt. Dafür ist der halt billig. Habe mit dem CH340 auch schon so meine leidigen Erfahrungen gemacht. W.S. schrieb: > Und soweit ich das im RefMan gelesen habe, sind alle Pins der > STM32F102xxx 5V-tolerant, es sei denn, man setzt sie in den > Analog-Modus. Soweit ich das verstanden habe sind die Pins, die die Möglichkeit eines Analogeingangs haben auch dann nicht (offiziell) 5V tolerant, selbst wenn sie als digitale Eingänge konfiguriert sind. Kann natürlich sein das sie es trotzdem verkraften.
Christopher J. schrieb: > W.S. schrieb: >> Und soweit ich das im RefMan gelesen habe, sind alle Pins der >> STM32F102xxx 5V-tolerant, es sei denn, man setzt sie in den >> Analog-Modus. > > Soweit ich das verstanden habe sind die Pins, die die Möglichkeit eines > Analogeingangs haben auch dann nicht (offiziell) 5V tolerant, selbst > wenn sie als digitale Eingänge konfiguriert sind. Kann natürlich sein > das sie es trotzdem verkraften. Ihr habt alle Recht, jeder für seinen Chip :) Der STM32F205 war auch so, wie W.S. schreibt. Der hatte auch immerhin noch 2 Pins mit Klemmdioden nach +3.3V. Aber es ist von Chip zu Chip verschieden und wird immer schlechter. Bei neueren Chips (z.B. L433, L476) gilt für alle Pins:
1 | Injected current: -5/+0 mA |
und
1 | Input voltage on FT_xxx pins: min (VDD, VDDA, VDDUSB, VLCD) + 4.0V |
Wenn also irgendeine Spannung fehlt, sind es offiziell nur 4.0 Volt, an allen Pins. Evt. findet man bei bestimmten Chips noch ein oder zwei Pins, die mehr vertragen, aber pauschal merkt man sich: STM32 -- nix 5 Volt.
W.S. schrieb: > Und soweit ich das im RefMan gelesen habe, sind alle Pins der > STM32F102xxx 5V-tolerant, es sei denn, man setzt sie in den Es ist ein F103 und bei dem sind nicht alle Pins 5V tolerant.
Christopher J. schrieb: > Bei Linux wird die serielle Schnittstelle erstmal wie eine Datei > behandelt, die man öffnen, lesen, beschreiben und schließen kann. Das > geht auch prinzipiell von mehreren Programmen gleichzeitig. Man kann > eine Schnittstelle in der Konsole mit Minicom, Picocom oder was auch > immer offen haben und gleichzeitig z.B. mit einem Pythonskript Daten auf > diese Schnittstelle senden. Ach herrje! Man hat eine serielle Schnittstelle NICHT modal? Bei Windows werden Dinge wie serielle Schnittstellen auch erstmal wie Dateien behandelt, aber man hat selbige modal, solange man sie nicht schließt. Da kommt einem keiner dazwischen. Das wäre ja auch ne Katastrophe. Stell dir mal vor, ein Programm benötigt HW-Handshake und ein anderes nicht und beide wollen auf die Serielle zugreifen. Und wie würde die Gegenseite die verschiedenen Datenströme auseinander halten? Man kann ja nicht wissen, was für ein grünes Marsmännchen auf der anderen Seite der Seriellen sitzt und wie es das Kauderwelsch versteht. W.S.
W.S. schrieb: > Bei Windows werden Dinge wie serielle Schnittstellen auch erstmal wie > Dateien behandelt, aber man hat selbige modal, solange man sie nicht > schließt. Nö! Wenn die Programme das unterstützen, können sie sich auch unter Windows eine Schnittstelle teilen.
Achso, und auch unter Linux kann man selbstverständlich eine Schnittstelle so öffnen, daß man sie exklusiv hat.
W.S. schrieb: > Ach herrje! Man hat eine serielle Schnittstelle NICHT modal? > > Bei Windows werden Dinge wie serielle Schnittstellen auch erstmal wie > Dateien behandelt, Und die sind nur deswegen nicht modal, weil bei Windoof per default nix shared geöffnet wird sondern man die Share Flags beim Öffnen explizit angeben muss. Wenn man das wirklich braucht, kann man IMHO auch im Windoof COM-Ports "sharen". Genauso kann man im Linux Dateien sperren (man fcntl). Macht da aber kaum jemand bei seriellen Schnittstellen.
W.S. schrieb: > Da kommt einem keiner dazwischen. Das wäre ja auch ne > Katastrophe. Stell dir mal vor, ein Programm benötigt HW-Handshake und > ein anderes nicht und beide wollen auf die Serielle zugreifen. Und wie > würde die Gegenseite die verschiedenen Datenströme auseinander halten? Naja, jede Schnittstelle ist eine eigene Datei. Was man damit für einen Unsinn treibt bleibt einem selber überlassen. guest schrieb: > Achso, und auch unter Linux kann man selbstverständlich eine > Schnittstelle so öffnen, daß man sie exklusiv hat. Es ist natürlich möglich zu schauen ob die Schnittstelle bereits von einem anderen Programm benutzt wird (Lock-File). Das kann man ignorieren, auch wenn man das nicht unbedingt sollte aber manchmal kann es auch praktisch sein, von mehreren Prozessen auf ein und dieselbe Schnittstelle zugreifen zu können. Ich weiß nicht ob man sich exklusiven Zugriff erzwingen kann (von Dateizugriffsrechten mal abgesehen) aber das ist ja auch eigentlich nicht das Thema. Wie ich schon vorher geschrieben habe liegt das Problem meiner Meinung nach nicht daran, wie serielle Schnittstellen im Allgemeinen vom Linux Kernel behandelt werden, sondern am CH340 bzw. dessen Treiber. Der TO wird es aber wahrscheinlich noch am ehesten Wissen. Edit: Jim M. schrieb: > Genauso kann man im Linux Dateien sperren (man fcntl). Macht da aber > kaum jemand bei seriellen Schnittstellen. Wusste ich auch noch nicht aber macht irgendwie Sinn, das es geht.
:
Bearbeitet durch User
Christopher J. schrieb: > Jim M. schrieb: >> Genauso kann man im Linux Dateien sperren (man fcntl). Macht da aber >> kaum jemand bei seriellen Schnittstellen. > > Wusste ich auch noch nicht aber macht irgendwie Sinn, das es geht. flock() und lockf() gibt (oder gab? bin da grad nicht ganz auf dem aktuellen Stand) es auch noch. Und irgendeine mount Option die damit zusammenhängt.
Christopher J. schrieb: > Der TO wird es aber wahrscheinlich noch am ehesten Wissen. ... es lag am CH340.... damit der unter Linux läuft war vorher ja auch ein Patch notwendig, weil er beim Treiber einen Bug mit Parity hat. Wie gesagt hab ich eine Lösung gefunden, ich kann sehr gut damit leben, dass ich die Puffer der seriellen Schnittstelle vor einem Upload leere.... Im übrigen trat dieses Priblem mit einem FTDI Chip nicht auf.... aber ich kann zum einen einen FTDI kaum verarbeiten und zum anderen kostet der deutluch mehr. Ansonsten hab ich mit dem CH340 kein Problem
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.