Ich bin hinsichtlich des Bootens/Flashens noch nicht weitergekommen mit dem Erforschen des mir hinterlassenen Aufbaus. Kann das System im Moment noch nicht flashen, da mein Vorgänger das Discoveryboard ziemlich stark verändert hat, insbesondere hinsichtlich des Bootloaders. Konnte nur eine Kopie des STM32F407 Boards anlegen auf dem Umweg, die Jumper wieder in den Originalzustand zu versetzen, dann ausgelesen mit dem st-link commandline tool und meine Kopie geflasht. Kurz und gut, arbeite jetzt mit der Kopie, habe aber keine Idee, wie ich mal eine modifizierte Programmversion flashen kann. Die mir vorliegende Schaltung hat einen BOOT0-Schalter, der den pin BOOT0 im Boot-Modus auf high legt (Pull-up). Das Programm selbst wird aber mit einem Skript aus dem BIN in ein Intel-Hex-Format konvertiert. Benutzt eines der ST-Flash-Utilities das Intel HEX-Format? Programmiert ist USART3 (BOOT0=1, BOOT1=0).
Ich kenne für STM32 kein Tool das HEX Dateien liest. Aber du hast ja auch eine BIN Datei, also nutze die doch einfach.
Stefan ⛄ F. schrieb: > Ich kenne für STM32 kein Tool das HEX Dateien liest. Aber du hast ja > auch eine BIN Datei, also nutze die doch einfach. Ich habe als Leitung aber nur den USART3 zur Verfügung. Weder der nördliche noch der südliche USB Anschluß stehen auf Grund der Boardmodifikation zur Verfügung. Mein Vorgänger muß den Code irgendwie anders da hineinbekommen haben.
Christoph K. schrieb: > Ich habe als Leitung aber nur den USART3 zur Verfügung. Nau und? Was hat das mit dem Dateiformat zu tun? Du hast BIN Dateien und du hast passende Tools die BIN Dateien als Input wollen. Wo ist das Problem?
Stefan ⛄ F. schrieb: > Ich kenne für STM32 kein Tool das HEX Dateien liest. Aber du hast ja > auch eine BIN Datei, also nutze die doch einfach. Also der STM32CubeProgrammer liest auch Intel Hex: https://www.st.com/en/development-tools/stm32cubeprog.html Und der im STM32F407 eingebaute Bootloader unterstützt auch USART3, soweit ich weiß.
Stefan ⛄ F. schrieb: > Christoph K. schrieb: >> Ich habe als Leitung aber nur den USART3 zur Verfügung. > > Nau und? Was hat das mit dem Dateiformat zu tun? Du hast BIN Dateien und > du hast passende Tools die BIN Dateien als Input wollen. Wo ist das > Problem? Das Problem ist z.B., daß ich mit dem ST-Flash Demoprogramm bisher kein Device erkennen kann.
Christoph K. schrieb: > Mein Vorgänger muß den Code irgendwie > anders da hineinbekommen haben. Er hat es womöglich mit einem einfachen externen Programmer mit SWD-Interface getan. Nachdem diese Programmer wirklich nur "Pfennigartikel" darstellen frage ich mich warum du dich solange herumquälst wo doch alles so einfach sein kann. Die SWD-Leitungen dürften ja wenigstens vorhanden sein ....
Christoph K. schrieb: > Das Problem ist z.B., das ich mit dem ST-Flash Demoprogramm bisher kein > Device erkennen kann. Das kann ja nichts mit deinen Dateien zu tun haben. Hast du 8 Datenbits und gerade Parität verwendet? Das muss schon sein. Die Baudrate wird automatisch erkannt. Ich verwende (mit STM32F1) im Zweifelsfall immer 38400, die laufen recht zuverlässig. Hast du alternativ den STM32 Cube Programmer versucht? Ansonsten geht auch dieses Programm: https://sourceforge.net/p/stm32flash/code/ci/master/tree/ (unter Linux weiß ich es mit Sicherheit, es soll aber auch Windows kompatibel sein).
> Nachdem diese Programmer wirklich nur "Pfennigartikel" darstellen > frage ich mich warum du dich solange herumquälst wo doch alles Naja, bei kommerzieller Nutzung sind das eher ein paar hundert Euro. Trotzdem wundert es mich das eine Firma sowas nicht rumliegen hat. Olaf
Olaf schrieb: > Naja, bei kommerzieller Nutzung sind das eher ein paar hundert Euro. > Trotzdem wundert es mich das eine Firma sowas nicht rumliegen hat. So wie er herumstöpselt und herumstochert ......... .......... kann das keine "Firma" sein.
STM32 Cube Programmer habe ich auch probiert. 38400,8E auch schon probiert. „Wer“ programmiert denn eigentlich den USART3 auf der Device-Seite?
Christoph K. schrieb: > „Wer“ programmiert denn eigentlich den USART3 auf der Device-Seite? Der fest eingebaute und unveränderliche Bootloader. USART3 kann auf zwei unterschiedlichen Pin-Pärchen liegen. Hast du das richtige verwendet (nicht das alternative)? Und (ich traue mich kaum zu fragen), hast du GND mit deinem USB-UART Adapter verbunden? Stimmen die Spannungspegel (nicht dass du 3,3V mit 5V kombinierst).
PB10/PB11 laut AN2606 Und USART3 ist auch der Console-Port der normalen Applikation. Also Verdrahtung ist nicht das Problem.
:
Bearbeitet durch User
jo mei schrieb: > Christoph K. schrieb: >> Mein Vorgänger muß den Code irgendwie >> anders da hineinbekommen haben. > > Er hat es womöglich mit einem einfachen externen Programmer mit > SWD-Interface getan. > Ich will möglichst die gleichen Pfade benutzen, die mein Vorgänger benutzt hat. Ein externer Programmer mit SWD-Interface ist nicht vorhanden. > Nachdem diese Programmer wirklich nur "Pfennigartikel" darstellen > frage ich mich warum du dich solange herumquälst wo doch alles > so einfach sein kann. Die SWD-Leitungen dürften ja wenigstens > vorhanden sein .... Ich weiß nicht, ob das Board nach der jetzigen Jumperung noch über SWD programmierbar ist, will ich aus o.g. Gründen auch nicht tun. Es ist ein Programm OCCONSOLE vorhanden, in dessen "Download"-Vorbesetzung eine .hex-Datei vorkommt. Deshalb liegt die Vermutung nahe, daß er einfach diese Datei hochgeladen hat.
Christoph K. schrieb: > Die mir vorliegende Schaltung hat einen BOOT0-Schalter, der den pin > BOOT0 im Boot-Modus auf high legt (Pull-up). Nur um der Genauigkeit willen: Ich glaube, es ist ein Schalter auf Vdd und ein 1K pulldown im offenen Fall (BOOT0=0).
:
Bearbeitet durch User
Christoph K. schrieb: > Ich will möglichst die gleichen Pfade benutzen, die mein Vorgänger > benutzt hat. OMG. Mein lieber Beamter, so wirst du noch weit kommen. Bloss nicht über den Tellerrand hinausschauen, das könnte Unglück bringen. Nächstes Jahr um diese Zeit wirst du dann zögernd die erste Zeile Programmcode versuchen zu ändern.
Christoph K. schrieb: > Ich will möglichst die gleichen Pfade benutzen, die mein Vorgänger > benutzt hat. Ein externer Programmer mit SWD-Interface ist nicht > vorhanden. Also wirklich, einen Original-STLink-V2 bekommt man um die 30€, einen V3 so um 35€, einen V3mods für unter 10€. Egal ob kommerzielle Verwendung. Bei letzterem vier dünne Litzen angelötet und ... > Ich weiß nicht, ob das Board nach der jetzigen Jumperung noch über SWD > programmierbar ist, will ich aus o.g. Gründen auch nicht tun. Das wäre höchstens bei RDP Level 2 ein Problem, aber da sich der Flash-Inhalt ja noch auslesbar war ... Jumper von CN3 ziehen, egal wie sonst an den Lötbrücken herumgewurschtelt wurde, zwei Fädeldrähte an die richtige Seite von SB3 und SB5, und dann hat sich's. Außerdem: Da sind ja nun wahrlich nicht Hunderte von Lötbrücken drauf. Das Abklappern derselben nach Schematics dauert doch nur ein paar Minuten. Nichts gegen gesunde Vorsicht, aber übertreiben sollte man es nun auch nicht. Was Bin vs. Intel-Hex anbelangt: objcopy, gehört zu den Arm-Binutils. Damit geht's von Elf nach Intel-Hex, Moto-Srec, Bin, ... lustig hin und her (naja, nach Elf zurück nicht). Aber welches Flash-Programm frißt nicht diverse Varianten? Zumindest Intel-Hex und Moto-Srec sind doch "Standard"
Danke, A.B., alles schön und gut, aber ich hätte gerne das Rätsel gelöst, wie mein Vorgänger das gemacht hat. Wie ich es später mache, sei dahingestellt. Habe vorsorglich mal so ein "Youmile" Klötzchen für 7,39€ bestellt. Würde trotzdem gerne herausbekommen, warum z.B. das ST-DemoFlashprogramm kein Device findet. Habe mal Folgendes gemacht: Im Normalbetrieb die Applikation gestartet, als Aktion eingegeben, daß die Applikation auf ein Zeichen wartet und dieses speichert. Konnte feststellen, daß das ST-Demoflash ein 0x7F sendet, so wie das in dem Bootprotokoll-Flowchart auch angegeben ist (Autobaud). Also stimmt zumindest die Kette vom Host zum UART3. Wenn ich jetzt in den BOOT-Mode gehe, müßte das ja auch so ablaufen. Ich habe noch ein RS485 USB-Kabel übrig. Könnte ich mit dem den USART3-Traffic "sniffen"? Geht das potentialmäßig und vom Level her?
Christoph K. schrieb: > Danke, A.B., alles schön und gut, aber ich hätte gerne das Rätsel > gelöst, wie mein Vorgänger das gemacht hat. Wenn du daran herum bastelst und es klappt irgendwann dann weist du immer noch nicht, ob dein Vorgänger es so gemacht hat. Da musst du dir eine andere Methode ausdenken, zum Beispiel ihn fragen, wenn er es nicht dokumentiert hat. Und dann mal den Chef informieren, dass er eine Qualitätskontrolle benötigt, die Dokumentation einschließt.
Christoph K. schrieb: > Ich habe noch ein RS485 USB-Kabel übrig. Könnte ich mit dem den > USART3-Traffic "sniffen"? Geht das potentialmäßig und vom Level her? Nein
Konnte gerade mittels OCConsole folgenden Test machen: Ein Macro definiert, das 0x7F sendet. Dann 500ms Pause und anschließend ein 0x00 gefolgt von 0xff. Es kommt nichts vom Device zurück. Könnte es eigentlich sein, daß der BOOT-Mode durch die Setzung der Jumper gar nicht enabled werden kann? Z.B. ist SB10 ja gebrückt.
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Da musst du dir > eine andere Methode ausdenken, zum Beispiel ihn fragen, wenn er es nicht > dokumentiert hat. Und dann mal den Chef informieren, dass er eine > Qualitätskontrolle benötigt, die Dokumentation einschließt. Das geht leider aus traurigen Gründen (†) nicht mehr. Er war immer sein eigener Chef.
:
Bearbeitet durch User
Christoph K. schrieb: > Könnte es eigentlich sein, daß der BOOT-Mode durch die Setzung der > Jumper gar nicht enabled werden kann? Z.B. ist SB10 ja gebrückt. Suche hier bei den Projekten einfach mal nach meinem STM32 Brennprogramm. Dort habe ich einige Service-Routinen mit eingebaut, damit man auch mal testen kann, ob Reset und Boot richtig ankommen usw. Man kann damit auch austesten, ob sich der Bootlader überhaupt meldet. Und es kann bin, hex und Motorola lesen. Das sollte reichen. W.S.
W.S. schrieb: > Christoph K. schrieb: >> Könnte es eigentlich sein, daß der BOOT-Mode durch die Setzung der >> Jumper gar nicht enabled werden kann? Z.B. ist SB10 ja gebrückt. > > Suche hier bei den Projekten einfach mal nach meinem STM32 > Brennprogramm. Dort habe ich einige Service-Routinen mit eingebaut, > damit man auch mal testen kann, ob Reset und Boot richtig ankommen usw. > Man kann damit auch austesten, ob sich der Bootlader überhaupt meldet. > Und es kann bin, hex und Motorola lesen. Das sollte reichen. > > W.S. Danke. Werde ich tun. Ich bin zwar schon soweit gekommen, daß ich - sagen wir mal so - "festzustellen meinte", daß der Bootloader nicht antwortet, indem ich ihm Kommandos schickte (GET 00FF) . Das sagt auch Dein Programm (STM32Prog): Teste Verbindung und Chip Bootlader reagiert nicht.
:
Bearbeitet durch User
Hast du mal dein Multimeter genommen und Reset und Boot im Programm am PC mal hoch und runter gesetzt und das mit dem MM kontrolliert? Nochwas: ich hab jetzt das Datenblatt deines µC nicht auswendig gelernt - aber hat der nur BOOT0 oder noch ein BOOT1 dazu? W.S.
W.S. schrieb: > Hast du mal dein Multimeter genommen und Reset und Boot im Programm am > PC mal hoch und runter gesetzt und das mit dem MM kontrolliert? > > Nochwas: ich hab jetzt das Datenblatt deines µC nicht auswendig gelernt > - aber hat der nur BOOT0 oder noch ein BOOT1 dazu? > > W.S. STM32F407G-DISC1 hat BOOT0 und BOOT1 Wenn ich RESET drücke und den BOOT0 High gelegt habe (per Schalter), dann geht die grüne LD7 an und BOOT0 ist auf 3,297 V. Was meinst Du mit "Reset und Boot im Programm am PC mal hoch und runter gesetzt"?
:
Bearbeitet durch User
Christoph K. schrieb: > geht die grüne LD7 an und BOOT0 ist auf 3,297 V. RxD und TxD müssen im Ruhezustand auch 3,3V haben. Ist das der Fall?
Christoph K. schrieb: > Was meinst Du mit "Reset und Boot im Programm am PC mal hoch und > runter gesetzt"? Christoph K. schrieb: > Das sagt auch Dein Programm (STM32Prog): > Teste Verbindung und Chip > Bootlader reagiert nicht. Ja was hast du denn da gemacht? Also: das normale Verfahren mit dem Bootlader ist, daß Reset und Boot0 vom PC aus über den seriellen Port gesteuert werden. So tut es auch mein Programm über DTR und RTS. Es legt Reset an, dazu Boot0, dann wird Reset wieder losgelassen und ab da sollte der Bootlader aktiv sein. Anschließend wird ein Synchronisationszeichen vom PC aus gesendet und ein ACK vom Bootlader erwartet. Prinzipiell kann man natürlich auch Boot0 manuell setzen, Reset drücken und dann erwarten, daß man damit in den Bootlader kommt. Aber da beim Arbeiten mit dem Bootlader ohnehin öfters mal ein Reset fällig ist, um klare Verhältnisse zu haben, sollte man das Steuern von Reset und Boot0 lieber dem Programm überlassen. Und um auszuprobieren, ob beide Signale ordentlich ankommen, gibt es dafür beim Port Setup sowohl die Einstellungen als auch Testknöpfe. Und Boot1 müßtest du passend manuell setzen bei Chips, die das haben. W.S.
Stefan ⛄ F. schrieb: > Christoph K. schrieb: >> geht die grüne LD7 an und BOOT0 ist auf 3,297 V. > > RxD und TxD müssen im Ruhezustand auch 3,3V haben. Ist das der Fall? PB10/PB11 sind es nicht. Sie sind auf 0V. Muß morgen die UART-Leitungen mal verfolgen und die Schaltung mal verifizieren. Im Normalbetrieb sind aber PB10/PB11 Uart3. Wundert mich, daß sie es im BOOT mode nicht sind. @W.S.: Hatte ja schon die ganze Zeit in meinen Posts erwähnt, daß es einen manuellen BOOT0-Schalter gibt und BOOT1 immer 0 ist. Stefans Hinweis auf die Rx/Tx-Pegel hat mich wahrscheinlich auf die richtige Fährte gebracht. Grüße Christoph EDIT: Kann jetzt schon sagen: PB10/PB11 sind im Normalmodus auf USART3 und gehen an den USB-Anschluß der umgebenden Schaltung (ein FTDI MM232R). Warum jetzt mit hochgelegtem BOOT0 und BOOT1=0 an PB10/11 kein USART3 ist, ist mir rätselhaft.
:
Bearbeitet durch User
Christoph K. schrieb: > Warum jetzt mit hochgelegtem BOOT0 und BOOT1=0 an PB10/11 kein USART3 > ist, ist mir rätselhaft. Hast du mal erwägt, dass der Mikrocontroller kaputt sein könnte? Was sagt denn der Schaltplan dazu, was genau hängt an den Pins? Deine Prosa zu zur Schaltung nervt mich ehrlich gesagt langsam. Wir wissen weder wie deine Schaltung aussieht, noch was du gemacht hast. Nicht einmal ein Foto magst du zeigen. Das fühlt sich an, als ob wir alle völlig ahnungslos über heiße Luft diskutieren, während sich der Boden unter unseren Füßen auflöst. Ernsthaftes Arbeiten sieht ganz anders aus!
Stefan ⛄ F. schrieb: > Wir wissen > weder wie deine Schaltung aussieht, noch was du gemacht hast. Nicht > einmal ein Foto magst du zeigen. > > Das fühlt sich an, als ob wir alle völlig ahnungslos über heiße Luft > diskutieren, während sich der Boden unter unseren Füßen auflöst. > Ernsthaftes Arbeiten sieht ganz anders aus! Danke sehr, es war Zeit dass das mal ausgesprochen wurde. Ich staune über die aufgrund dieses Verhaltens die immer noch vorhandene Motivation einiger Leute. jo mei schrieb: > So wie er herumstöpselt und herumstochert .........
Angehängte Dateien:
-
IMG_6926.jpg
240 KB
Christoph K. schrieb: > Stefan ⛄ F. schrieb: >> Christoph K. schrieb: >>> geht die grüne LD7 an und BOOT0 ist auf 3,297 V. >> >> RxD und TxD müssen im Ruhezustand auch 3,3V haben. Ist das der Fall? > > PB10/PB11 sind es nicht. Sie sind auf 0V. Muß morgen die UART-Leitungen > ... > > EDIT: Kann jetzt schon sagen: PB10/PB11 sind im Normalmodus auf USART3 > und gehen an den USB-Anschluß der umgebenden Schaltung (ein FTDI > MM232R). > > Warum jetzt mit hochgelegtem BOOT0 und BOOT1=0 an PB10/11 kein USART3 > ist, ist mir rätselhaft. Hatte noch einen Fehler in meinem Klone-Board festgestellt, SB-11 war noch geschlossen. Habe ihn geöffnet. Jetzt sind zumindest PB10/PB11 auch im BOOT-Modus High (3,3V). So sind die Jumper-Settings (gelistet nur die mit Änderung gegenüber Default): SB3,5,7,9 OFF SB10 (STM_RST) ON SB11 (NRST) OFF SB12 (SWO) OFF SB18 (BOOT0) OFF SB20 (B1-USER) OFF Trotzalledem regt sich kein Bootloader an PB10/11 (USART3).
Stefan ⛄ F. schrieb: > Christoph K. schrieb: >> Warum jetzt mit hochgelegtem BOOT0 und BOOT1=0 an PB10/11 kein USART3 >> ist, ist mir rätselhaft. > > Hast du mal erwägt, dass der Mikrocontroller kaputt sein könnte? Nein, habe ich nicht erwogen, da die Applikation läuft. > > Was sagt denn der Schaltplan dazu, was genau hängt an den Pins? Deine An den Pins hängt ein Si8621AB, dessen andere Seite zum MM232R (FTDI) geht.
Christoph K. schrieb: >> Hast du mal erwägt, dass der Mikrocontroller kaputt sein könnte? > Nein, habe ich nicht erwogen, da die Applikation läuft. Nutzt die Applikation denn den USART3 an diesen beiden Pins? Wenn nicht, dann ist dein Rückschluss falsch. Kaputte ungenutzte I/O Pins legen die Applikation nicht lahm.
Angehängte Dateien:
-
IMG_6931.jpg
230 KB
Stefan ⛄ F. schrieb: > Christoph K. schrieb: >>> Hast du mal erwägt, dass der Mikrocontroller kaputt sein könnte? >> Nein, habe ich nicht erwogen, da die Applikation läuft. > > Nutzt die Applikation denn den USART3 an diesen beiden Pins? Wenn nicht, > dann ist dein Rückschluss falsch. Kaputte ungenutzte I/O Pins legen die > Applikation nicht lahm. Ja, ich kann im Normalmodus genau über diesen USART3 mit der Applikation über den COM-Port kommunizieren. 38400 Bd, 8N1. (ja, ich weiß, im BOOT mode wird die Port mit EVEN Parity betrieben). Wenn ich das Flash Loader Demonstrator-Utility entsprechend einstelle, findet das kein Device. Was macht eigentlich das NRST-Signal? Bei der Jumperung von SB10 (connect) liegt es ja auf GND (aber am STM32F103C8T6, nicht an der MCU). Kann das trotzdem was mit dem Nichtfunktionieren des BOOT-Protokolls zu tun haben? Auch auf die Gefahr hin, daß ich jetzt wieder in Prosa verfalle, aber die Protoschaltung ist so gestaltet, daß sie das Ausgangsmodell für die in PCB (EAGLE) zu gießende Schaltung ist, weshalb ziemlich viel auf dem Discovery Board disabled ist (siehe Jumperung) und Entfernung von Bauelementen im Bereich PA9/PA10 (UART1).
:
Bearbeitet durch User
Christoph K. schrieb: > Konnte gerade mittels OCConsole folgenden Test machen: > > Ein Macro definiert, das 0x7F sendet. Dann 500ms Pause und anschließend > ein 0x00 gefolgt von 0xff. Es kommt nichts vom Device zurück. Normalerweise sendet der Bootloader schon nach dem 0x7F ein 'y'. Theoretisch könnte der Bootloader irgendeine andere Schnittstelle als UART3 aktivieren. Zum Beispiel, wenn an der anderen ein unruhiges Analog-Signal angeschlossen ist. Oder wenn er glaubt, dass eine USB-Verbindung aktiv ist.
Bauform B. schrieb: > Christoph K. schrieb: >> Konnte gerade mittels OCConsole folgenden Test machen: >> >> Ein Macro definiert, das 0x7F sendet. Dann 500ms Pause und anschließend >> ein 0x00 gefolgt von 0xff. Es kommt nichts vom Device zurück. > > Normalerweise sendet der Bootloader schon nach dem 0x7F ein 'y'. OK. Danke für den Hinweis. Dieses ACK ('y') habe ich nicht gesehen. Also deutet vieles darauf hin, daß der Bootloader an dem Port nicht aktiv ist. Wahrscheinlich brauchte ich noch mal ein neues STM32F407G-DISC1 Board als Referenz. Hat jemand eines herumliegen?
Christoph K. schrieb: > Was macht eigentlich das NRST-Signal? Also die Schaltung deines Boards hat unsereiner nicht auswendig gelernt, aber für gewöhnlich ist das die Bezeichnung für das Reset-Signal. Das N am Anfang soll dabei andeuten, daß dieses Low-aktiv ist. Allerdings verwirrt mich deine weitere Auskunft, daß es wohl gar nicht an den STM32F407 geht, sondern wohl an einen ST-Link auf dem Board. Schaue also lieber mal, was das NRST-Signal des STM32F407 ist und wo es hingeht. Christoph K. schrieb: >... weshalb ziemlich viel auf dem > Discovery Board disabled ist (siehe Jumperung) und Entfernung von > Bauelementen im Bereich PA9/PA10 (UART1). Na dann hättest du diesen UART ja frei und an selbigem sollte sich dein Bootlader melden, wenn du deinen Chip nicht kaputt gemacht hast. Also schließe deine serielle Programmierstrippe mal dort an, dazu auch noch NRST (das zum 'F407 gehörige!) und Boot0. Dann sollte das Ganze auch funktionieren. W.S.
Angehängte Dateien:
-
IMG_6934.jpg
230 KB
Auswendig lernen verlangt ja auch keiner. Die Schaltung steht ja in der Dokumentation des STM32F407G-DISC1 auf Seite 36 (DM00039084.pdf) . Dazu hatte ich die momentanen Jumper-Settings ja gepostet: SB11 - OFF => NRST vom SWD Connector nicht zum NRST der MCU verbunden. SB10 - ON => NRST am STM32F103C8T6 ist auf GND. Noch mal zu Verständnis: das Discovery-Board ist Bestandteil der Gesamtschaltung (Protoaufbau). Letztere ist der Prototyp von dem, was final in die Schaltung des Gesamtsystems eingeflossen ist. Davon liegen Schaltpläne vor, der Protoaufbau muß aber nicht identisch mit der finalen Schaltung sein. Zum NRST: Laut Discoveryboard-Schaltplan geht der an SB11 und endet dort, weil SB11 unterbrochen ist. Momentan liegt also NRST (14 der MCU) an gar nichts (bis auf den RESET-Taster via SB1). Nichts zwingt mich jetzt , SB11 offen zu lassen, wenn nicht andere Gründe dagegen sprechen, daß ich das SWD-Interface nicht zum Programmieren benutzen kann. Habe heute diesen externen USB ST-LINK V2 bekommen (s. Photo). Schön wäre es natürlich trotzdem, ich könnte das Rätsel mit dem nicht antwortenden USART3 im BOOT-Mode lösen. Vielleicht noch eine Beobachtung: BOOT0 ist definitiv an Vdd (3,29V), BOOT1 (PB2 immer über 510 Ohm an Masse)
Christoph K. schrieb: > Auswendig lernen verlangt ja auch keiner. verbindlichsten Dank dafür. > Die Schaltung steht ja in der > Dokumentation des STM32F407G-DISC1 auf Seite 36 Sehr schön, aber das müßtest du schon selber lesen, denn wenn ich das lese, hättest du ja nix davon, gelle? Quintessenz des Ganzen: Wenn du es nicht schaffst, mit dem Bootlader auf UART3 zu Potte zu kommen, dann mag das eventuell daran liegen, daß der Bootlader diesen Port gar nicht bedient, sondern lieber auf UART1 arbeitet. Die nötigen Tools und Hinweise hast du, also mache es einfach. W.S.
W.S. schrieb: ... > Quintessenz des Ganzen: Wenn du es nicht schaffst, mit dem Bootlader auf > UART3 zu Potte zu kommen, dann mag das eventuell daran liegen, daß der > Bootlader diesen Port gar nicht bedient, sondern lieber auf UART1 > arbeitet. Die nötigen Tools und Hinweise hast du, also mache es einfach. > > W.S. Danke. Gut, bleibt zwar die Frage, warum USART3 in der ST- Doku erwähnt ist. Aber gut, werde es versuchen, wenn ich jetzt nicht doch den externenST-Link V2 einsetze. Grüße Christoph
Angehängte Dateien:
-
STM32f4-disco.jpg
190 KB
habe eben ein China Board mit F407 genommen, Boot0 auf 1, Boot1 liegt per 10k an GND, PB10 an Rx, PB11 an Tx angeschlossen, einmal Reset gedrückt. STM32CubeProgrammer gestartet, auf UART gestellt, COM Port eingestellt, Connect gedrückt, fertig. ChipID wird gelesen, Funktioniert. Sowohl mit default 115200 als auch mit 38400 Bit/s. Edit: und auch das ältere Discovery funktioniert ad hoc mit dem Cube Programmer per UART an PB10/PB11.
@jojos: was mich bei Deinem Discovery wundert, ist, daß die grüne LED (LD7) bei der BOOT- Konfiguration nicht angeht. Bei mir ist die an, was natürlich sein kann, weil im Bereich von PA9/10 (UART1) Änderungen gemacht wurden.
:
Bearbeitet durch User
LD7 ist laut User Manual 'VBus active', aber USB habe ich ja auch nicht angeschlossen.
Johannes S. schrieb: > LD7 ist laut User Manual 'VBus active', aber USB habe ich ja auch nicht > angeschlossen. Dann muß ich mir die Modifikationen noch mal ansehen, welche Auswirkung die haben. Morgen aber erst. Danke einstweilen für die Testberichte.
Angehängte Dateien:
Hier sind die Modifikationen, die am Discovery gemacht wurden im Bereich des OTG-USB. Kann natürlich sein, daß PA10 (USART1 RxD) da - weil floating - den BOOT-Loader irritiert und da Input vortäuscht.
wenn PA11/12 offen sind, dann sollten die nicht stören. Auf jeden Fall ohne USB Kabel probieren, ich habe auch nur die gezeigten Leitungen angeschlossen. Als Versorgung habe ich die +5V vom FTDI Adapter genommen.
Angehängte Dateien:
-
IMG_6935.jpg
230 KB
Johannes S. schrieb: > wenn PA11/12 offen sind, dann sollten die nicht stören. Auf jeden Fall > ohne USB Kabel probieren, ich habe auch nur die gezeigten Leitungen > angeschlossen. Als Versorgung habe ich die +5V vom FTDI Adapter > genommen. Um PA9/PA10 geht's hier. EDIT: OK, Du meintest die Controlsignale. Habe jetzt Erfolg: Habe einen FTDI/USB Serial Adapter geopfert, da ich nicht so ein fertiges gelbes Teil hatte Du wie in Deinem Bild. Das Ding war in WeichPVC vergossen und ich mußte es erst aufprokeln, um an die Pins 24/25 vom FTDI232BL Chip zu kommen. An PA9/PA10 angeschlossen und DemonstratorGUI findet das Device. Warum USART3 nicht geht, weiß ich allerdings immer noch nicht. Können Schnittstellensteuersignale (RTS, CTS) einen Einfluß haben?. Wenn ich im normalen Betried mit der Schaltung kommuniziere, geht 8N1 ohne weitere Schnittstellensignale. EDIT: Am USB hängt das Discoveryboard ohnehin nicht. Wir über die Breakout-Pfostenreihen versorgt.
:
Bearbeitet durch User
Christoph K. schrieb: > Können Schnittstellensteuersignale (RTS, CTS) einen Einfluß haben? Nicht auf den Bootloader, der kennt sowas garnicht. Manche Leute (z.B. W.S.) schließen die statt der Taster für NRST und BOOT an, dann ja, aber das machst du doch nicht? Am anderen Ende (Windows, Terminalprogramm usw.) werden RTS und CTS gerne zur Fluss-Steuerung verwendet. Dabei blockiert ein falscher Pegel die Kommunikation. Der FTDI-Konverter erzeugt per Default die richtigen Pegel, also funktioniert es immer. Ich finde es aber unwahrscheinlich, dass sich der Demo-Loader davon stören lässt. > Wenn ich im normalen Betried mit der Schaltung kommuniziere, > geht 8N1 ohne weitere Schnittstellensignale. Der Bootloader geht auch alleine mit RX und TX (nur eben 8E1 statt 8N1). "Meistens" sind bei solchen Versuchen ja RX und TX vertauscht, aber dann würde der normale Betrieb doch auch nicht funktionieren. Es gibt wohl STM32-Modelle, die RX und TX per Software vertauschen können, aber doch nicht der F407?
wie ich das verstanden habe soll der Bootloader selber die richtige Schnittstelle finden. Wenn jetzt also PB10/PB11 verwendet werden soll, aber an anderen Schnittstellen jetzt auch irgendwas passiert, dann weiß ich nicht ob der Bootloader damit noch klarkommt. Insofern könnte andere Hardware an den Pins Ärger machen. Vielleicht wurde bei dem Board ja auch ein eigener Bootloader in der Applikation benutzt, man kann den Controller ja auch mit eigener Software programmieren.
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.