STM32F407VG mittels µC oder FPGA flashen

> Das muss doch irgendwie gehen.

Natuerlich geht das. Falls ST das Verfahren nicht offen gelegt hast 
schliesst du einfach einen Debugger an die SWD-Schnittstelle an und 
schaust mal wie dein J-Link das macht und programierst es nach.

Den meisten Leuten ist das aber zu aufwendig. Sie schreiben sich einfach 
einen eigenen Bootloader der immer im Flashrom bleibt und der nimmt dann 
die Daten auf der Schnittstelle der eigenen Wahl entgegen und beschreibt 
den Controller. Ist ueberhaubt kein Problem.

Olaf

Google "stm32 bootloader", z. B.

http://www.st.com/resource/en/application_note/cd00264342.pdf

Wer suchet, der findet ...

A. B. schrieb:
> http://www.st.com/resource/en/application_note/cd00264342.pdf
>
> Wer suchet, der findet ..

Also ginge es damit ohne eigenen Bootloader?
In welchem Format muss dann das Binary sein? elf oder bin?
Muss ich dann beim Kompilieren irgendwas anders machen oder beachten (im 
Vergleich zu CoFlash.exe)?

Olaf schrieb:
> Den meisten Leuten ist das aber zu aufwendig. Sie schreiben sich einfach
> einen eigenen Bootloader der immer im Flashrom bleibt und der nimmt dann
> die Daten auf der Schnittstelle der eigenen Wahl entgegen und beschreibt
> den Controller. Ist ueberhaubt kein Problem.

"einfach einen eigenen Bootloader"
Das ist leicht gesagt. Habe mal vorher etwas quer gelesen und das 
scheint nicht ohne zu sein, z.B.
  Beitrag "STM32F4 In Application Programming"
Ist das in einem der AN von STM gut beschrieben?

> "einfach einen eigenen Bootloader"
> Das ist leicht gesagt. Habe mal vorher etwas quer gelesen und das
> scheint nicht ohne zu sein, z.B.

Wieso? Du programmierst doch jetzt auch oder? Ein Bootloader 
unterscheidet sich durch nichts von deinen aktuellen Programmen. 
Lediglich die Goto-Funktion am Ende um in dein neues Hauptprogramm zu 
springen ist vielleicht etwas neues.

Und fuer deine Anwendungsprogramme aendert sich nur die Adresslage an 
weil sie natuerlich nicht im Bootloadersegment liegen duerfen. Dazu 
passt du einfach dein Linkerscript an.

Das war es dann auch schon...

Olaf

Olaf schrieb:
> Und fuer deine Anwendungsprogramme aendert sich nur die Adresslage an
> weil sie natuerlich nicht im Bootloadersegment liegen duerfen. Dazu
> passt du einfach dein Linkerscript an.

Das ist mir neben vielen Dingen auch noch nicht ganz klar:
Wenn ich mit CooCox "ganz normal" eine elf-Datei erzeuge und das 
Discovery-Board flashe, ist dann auf dem µC irgendwie ein 
Standard-Bootloader vorhanden, der durch den Schreibvorgang gar nicht 
berührt wird, und die elf Datei wird dahinter geschrieben oder schreibt 
CooCox immer automatisch einen Bootloader mit (oder steckt der sogar mit 
in der elf-Datei)?


Olaf schrieb:
> Wieso? Du programmierst doch jetzt auch oder? Ein Bootloader
> unterscheidet sich durch nichts von deinen aktuellen Programmen.

Ja klar  programmiere ich jetzt auch. Aber irgendwie muss sich ein 
Bootloader ja doch von einem normalen Programm unterscheiden 
(Initialsierungen, Adresse im Linker-Srkipt?) und ich wüsste gerne wie.
Gibt es da nicht irgendeine Vorlage?
Wenn man diese Threads so liest, ist wenig Konkretes zu finden:
  Beitrag "Custom Bootloader für Stm32"
  Beitrag "Custom Bootloader für den STM32??"


> Lediglich die Goto-Funktion am Ende um in dein neues Hauptprogramm zu
> springen ist vielleicht etwas neues.

Hättest Du für diese "Goto-Funktion" mal ein Beispiel?

Sebastian K. schrieb:
> Einen Bootloader nach deinem Verständnis gibt es nicht. Es gibt
> lediglich einen "Einstiegspunkt" im Adressraum des uC. Um den
> Einstiegspunkt beim Power-On festzulegen, setzt du den zwei Boot Pins
> BOOT0 und BOOT1 des Controllers entsprechend. Damit legst du fest, ob
> der uC das Programm im Flash, den System Bootloader oder das SRAM
> anspringt.

Also ist ein Bootloader nach meinem Verständnis (nämlich in meinem Fall 
ein Programm, welches ein anderes per UART nachlädt), bzgl. der Struktur 
(Startadresse im µC) identisch zu einem Programm, das z.B. eine LED 
blinken lässt, nur dass es eben eine andere Funktionalität hat?


Sind denn dann z.B. die Bootloader
  - OpenBLT oder
  https://github.com/rowol/stm32_discovery_arm_gcc/tree/master/STM32F4-Discovery_FW_V1.1.0
auch  Bootloader nach meinem Verständnis (d.h. der System-Bootloader 
wird nicht überschrieben - nicht dass ich das Board "bricke")?

>> Das ist leicht gesagt. Habe mal vorher etwas quer gelesen und das

Lesen bildet, "Querlesen" eher weniger. Auf der ST-Website gibt's 
haufenweise App. Notes zu dem fest einprogrammierten Bootloader, welchen 
Schnittstellen bedient werden, Infos wie man die Bootmodi aktiviert, 
Errata usw. Man muss halt nur gründlich lesen wollen.

Die Erwartungshaltung, dass jemand anders einem alles schön mundgerecht 
auf dem Silbertablett serviert, ist schon etwas dreist.