Forum: Mikrocontroller und Digitale Elektronik STM32F407G Bootloader - andere Bootmöglichkeit?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Christoph K. (chriskuku)


Bewertung
-1 lesenswert
nicht lesenswert
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).

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Ich kenne für STM32 kein Tool das HEX Dateien liest. Aber du hast ja 
auch eine BIN Datei, also nutze die doch einfach.

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Tassilo H. (tassilo_h)


Bewertung
2 lesenswert
nicht lesenswert
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ß.

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
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.

von jo mei (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ....

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
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).

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von jo mei (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
STM32 Cube Programmer habe ich auch probiert. 38400,8E auch schon 
probiert.

„Wer“ programmiert denn eigentlich den USART3 auf der Device-Seite?

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
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).

: Bearbeitet durch User
von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
PB10/PB11 laut AN2606

Und USART3 ist auch der Console-Port der normalen Applikation. Also 
Verdrahtung ist nicht das Problem.

: Bearbeitet durch User
von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
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
von jo mei (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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"

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
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

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
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
von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
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
von W.S. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
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
von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
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
von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
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?

von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
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
von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
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!

: Bearbeitet durch User
von jo mei (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 .........

von Christoph K. (chriskuku)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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).

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Christoph K. (chriskuku)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
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?

von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Christoph K. (chriskuku)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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)

von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
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

von Johannes S. (jojos)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
@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
von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
LD7 ist laut User Manual 'VBus active', aber USB habe ich ja auch nicht 
angeschlossen.

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Christoph K. (chriskuku)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Christoph K. (chriskuku)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.