STM32 Nucleo DFU

Horst schrieb:
> Kann man über den ST-Link eine DFU-Datein flashen?
Nein.

Um diese Dateien zu flashen, muss sich der STM32 im Bootloadermodus 
befinden. Das geht entweder über die Boot-Pins (Hardware), oder per 
Software über einen Jump auf die Adresse des internen ST-Bootloaders.

Ein hilfreiches Video hierzu:
https://community.st.com/videos/1418-stm32-dfu-bootloader-howto

Noch eine kleine Ergänzung zu den Hardware-Pins. Diese sind auf den 
Evalboards verschieden, bzw. sind die Bootpins meist nicht auf dem PCB 
aufgedruckt.

Hier findet sich eine Übersicht für die gängigen STM32-Boards am 
Beispiel Micropython (spielt keine Rolle, da es ja nur um das Übertragen 
des DFU Files geht) 
https://www.14core.com/flashing-bootloading-stm32-arm-with-micropython/

>Ein hilfreiches Video hierzu:
>https://community.st.com/videos/1418-stm32-dfu-boo...

Danke für den Link. Wenn ich das richtig sehe, muss man eine USB-Kabel 
für das Nucleo-Board löten.

Eigentlich ist ja schon ein ST-Link auf dem Board. Gibt es keine 
einfachere Möglichkeit das Board zu flashen? Kann man aus dem *.dfu ein 
*.bin machen?

Horst schrieb:
> Gibt es keine
> einfachere Möglichkeit das Board zu flashen?

Man kann ja auch über UART/USART den Bootloader speisen.
Bei den STM32F4xx Controllern stehen USART1 und USART3
zur Verfügung.

Der Programmer für das Board hat den STLink + das mbed MSD drauf, damit 
meldet sich sich das Board am PC als Massenspeicher an. Zum 
Programmieren muss nur das binary auf dieses Laufwerk kopiert werden.
Was soll das *.dfu file denn enthalten?
Damit das Target per dfu_util programmiert werden kann muss da erstmal 
ein Bootloader drauf und du musst eine USB Buchse anschliessen. Die 
Buchse am Board geht an den STLink, die hat keine direkte Verbindung zum 
Target.

>Der Programmer für das Board hat den STLink + das mbed MSD drauf, damit
>meldet sich sich das Board am PC als Massenspeicher an. Zum
>Programmieren muss nur das binary auf dieses Laufwerk kopiert werden.
>Was soll das *.dfu file denn enthalten?

Um bei dem Beispiel Micropython zu bleiben:
Für das STM32L476RG Nucleo gibt es ein fertig compiliertes DFU-File:
https://micropython.org/download#other

>meldet sich sich das Board am PC als Massenspeicher an.
Ich habe das DFU-File mal da reingeschoben. Es passiert nichts.

Horst schrieb:
>>meldet sich sich das Board am PC als Massenspeicher an.
> Ich habe das DFU-File mal da reingeschoben. Es passiert nichts.

Das funktioniert auch nicht mit DFU-Files.

Ich werfe noch mal einen Link in die Runde, als Ergänzung zu dem was 
Johannes gesagt hat. Man muss sich die USB-Verbindung zwischen PC und 
dem STM32-Hauptcontroller erst einmal herstellen. Wie Johannes gesagt 
hat, ist der USB-Anschluss auf dem Nucleo nur mit dem ST-Link verbunden.

https://mobilewill.us/stm32-nucleo-and-dfu-usb-bootloading/

Gerade habe ich Micropython von hier gezogen:
https://github.com/micropython/micropython

Mit make wird nicht nur ein *.dfu, sondern auch ein *.hex file und zwei 
bin-files erzeugt.
Das ist schon mal viel versprechend ...

>Ich werfe noch mal einen Link in die Runde, als Ergänzung zu dem was
>Johannes gesagt hat. Man muss sich die USB-Verbindung zwischen PC und
>dem STM32-Hauptcontroller erst einmal herstellen. Wie Johannes gesagt
>hat, ist der USB-Anschluss auf dem Nucleo nur mit dem ST-Link verbunden.

>https://mobilewill.us/stm32-nucleo-and-dfu-usb-bootloading/

Danke für den Link, das ist sehr gut dokumentiert.

Mir ist das jetzt aber alles zu kompliziert. Jedesmal, wenn ich dieses 
Nucleo-Board in die Hand nehme, geht irgendwas nicht.
Ich werf's erst mal wieder in die Ecke. Soll es da schmoren :-(

Was spricht gegen das Programmieren mit dem OnBoard ST-Link?

Die Nucleo Boards sind eigentlich sehr gut und die zugehörige Software 
arbeitet zuverlässig. Ich fürchte, du musst Dir ein anderes Hobby suche, 
wenn diese bei Dir so viel Frust auslösen.

Oder du übst Dich in Geduld. Vielleicht helfen Dir meine Notizen zum 
STM32F1, das ist zwar eine andere Serie aber was dort steht gilt 
weitgehend auch für Dein Modell. http://stefanfrings.de/stm32/index.html

Es geht ja vermutlich nicht um das Board sondern darum microPython 
darauf zu bringen.
Im Prinzip sollte das gehen mit dem richtigen bin file. Und man kann die 
Quellen evtl. so ändern das nicht direkt über den eigenen USB sondern 
über den VCOM des STLink kommunziziert wird. Habe das microPython nur 
kurz überflogen, die Portierungen sind da nicht dokumentiert? Da wird es 
aber auch Foren geben wo das schnell beantwortet werden kann.

bzw. ist auf dieser Seite ein Absatz zur Programmierung mit dem ST-Link:
https://github.com/micropython/micropython/tree/master/ports/stm32

>Die Nucleo Boards sind eigentlich sehr gut und die zugehörige Software
>arbeitet zuverlässig. Ich fürchte, du musst Dir ein anderes Hobby suche,
>wenn diese bei Dir so viel Frust auslösen.

Oha, starke Worte.
Python wurde mit dem Anspruch an Einfachheit entwickelt. Das Prinzip der 
Einfachheit ist ein Gutes. Die Nucleo-Boards den Nucleo-Boards öffnet 
sich beim einstecken ja das Massespeicherfenster. Einfach wäre es also, 
ein vorkompiliertes Binärfile dort hineinzuschieben. Fertig, läuft. Eine 
Sache von 3 Minuten. Aber nein, so soll es nicht sein.
Diese ewige Akzeptanz der Softwarenachlässigkeit führt genau zu dieser 
Imperfektion.

Ein Vorschlag: gibt Dir 15 Minuten um Micropython auf dem Board zu 
installieren. Wenn Du es bis dahin nicht schaffst, wirf den kleinen 
Zeitfresser aus dem Fenster.

Schon etwas älter, aber immer noch mit viel Wahrheit:
https://www.youtube.com/watch?v=BKfTlJ06Eu0

> Einfach wäre es also, ein vorkompiliertes Binärfile dort
> hineinzuschieben. Fertig, läuft.

So funktioniert das auch, wenn du ein *.bin File verwendest. Diese 
Möglichkeit, Firmware hoch zu laden, unterstützen auch viele andere 
Boards anderer Hersteller.

Wenn deine Python Software kein passendes File bereit stellt, dass ist 
dein Python wohl doch nicht so einfach. Dafür jetzt das Nucleo Board in 
die Ecke zu werfen ist der falsche Weg. Das kann nichts dafür.

> gibt Dir 15 Minuten

Ich halte sehr viel mehr Geduld für angemessen. Mit der Einstellung 
wirst du keine brauchbare Software entwickeln.

> Diese ewige Akzeptanz der Softwarenachlässigkeit

welche von ungeduldigen Leuten mit dieser Einstellung produziert 
wird....

Denk mal drüber nach.