Frage zum STM32F439 Boot-Vorgang und zum Flashen.

[Markus W. (dl8mby)]

Hallo Forum,
hallo ARM  und insbesondere ST Spezialisten,

ich bin gerade dabei den o.g. mcHF SDR-Sendeempfänger aus dem HF-Forum 
zusammen zu bauen und habe noch ein Problem beim Flashen der Firmware.

Details zum Gerät siehe Beitrag:

Beitrag "Re: mcHF-SDR Selbstbau-Projekt"

Möglicherweise könnte mir einer von Euch auf die Sprünge helfen.

Vorweg einige Besonderheiten bei meinem Gerät, die von der Mainstream
abweichen, weshalb ich nicht im Yahoo- und auch nicht im mcHF-Forum vom
OV Sulingen frage.

1) ich verwende als MC den STM32F439VI (größerer Flash und RAM und 
180MHz CPU Takt)

2) Ich programmiere den MC via ST-Link Stick (SW_CLK, SW_DIO, NRST, GND) 
unter Linux.

Der Bootloader wird über das Kommando:

st-flash write ./bootloader.dfu 0x08000000

auf der Kommandozeile programmiert, die zugehörige FW ebenso mit:

st-flash write ./mchf-20160325.bin 0x08010000


Beide Kommandos geben einen OK-Status zurück:

Für den Bootloader:
===================
2016-03-25T20:20:46 INFO src/stlink-common.c: Loading device 
parameters....
2016-03-25T20:20:46 INFO src/stlink-common.c: Device connected is: F42x 
and F43x device, id 0x10076419
2016-03-25T20:20:46 INFO src/stlink-common.c: SRAM size: 0x40000 bytes 
(256 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 16384 bytes
2016-03-25T20:20:46 INFO src/stlink-common.c: Attempting to write 23201 
(0x5aa1) bytes to stm32 address: 134217728 (0x8000000)
2016-03-25T20:20:46 WARN src/stlink-common.c: unaligned len 0x5aa1 -- 
padding with zero
EraseFlash - Sector:0x0 Size:0x4000
Flash page at addr: 0x08000000 erasedEraseFlash - Sector:0x1 Size:0x4000
Flash page at addr: 0x08004000 erased
2016-03-25T20:20:47 INFO src/stlink-common.c: Finished erasing 2 pages 
of 16384 (0x4000) bytes
2016-03-25T20:20:47 INFO src/stlink-common.c: Starting Flash write for 
F2/F4/L4
2016-03-25T20:20:47 INFO src/stlink-common.c: Successfully loaded flash 
loader in sram
enabling 32-bit flash writes
size: 23202
2016-03-25T20:20:48 INFO src/stlink-common.c: Starting verification of 
write complete
2016-03-25T20:20:48 INFO src/stlink-common.c: Flash written and 
verified! jolly good!

und für die FW:
===============
2016-03-25T20:20:58 INFO src/stlink-common.c: Loading device 
parameters....
2016-03-25T20:20:58 INFO src/stlink-common.c: Device connected is: F42x 
and F43x device, id 0x10076419
2016-03-25T20:20:58 INFO src/stlink-common.c: SRAM size: 0x40000 bytes
(256 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 16384 bytes
2016-03-25T20:20:58 INFO src/stlink-common.c: Attempting to write 245356 
(0x3be6c) bytes to stm32
address: 134283264 (0x8010000)
EraseFlash - Sector:0x4 Size:0x10000
Flash page at addr: 0x08010000 erasedEraseFlash - Sector:0x5 
Size:0x20000
Flash page at addr: 0x08020000 erasedEraseFlash - Sector:0x6 
Size:0x20000
Flash page at addr: 0x08040000 erased
2016-03-25T20:21:01 INFO src/stlink-common.c: Finished erasing 3 pages 
of 131072 (0x20000) bytes
2016-03-25T20:21:01 INFO src/stlink-common.c: Starting Flash write for 
F2/F4/L4
2016-03-25T20:21:01 INFO src/stlink-common.c: Successfully loaded flash 
loader in sram
enabling 32-bit flash writes
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 15980
2016-03-25T20:21:07 INFO src/stlink-common.c: Starting verification of 
write complete
2016-03-25T20:21:13 INFO src/stlink-common.c: Flash written and 
verified! jolly good!

Die FW wurde mit folgenden Linker Einstellungen gebaut - siehe
arm-gcc-link.ld


Nun zu meinem Problem:

Nach dem Flashen der FW startet das Programm automatisch, und alles 
sieht sehr gut aus.
Schalte ich das Gerät aus, kommt nach dem erneuten PowerOn (via 
Netzteil) nur ein weißer
Bildschirm, d.h. nur die Hintergrundbeleuchtung leuchtet.

Nach meinem jetzigen ARM/ST Wissensstand, bin ich der Meinung, dass der 
MC von
irgendeiner Startadresse im Flash (irgendwo bei Range 0xFFFFFFF - 
0xFFFxxxx) die Adresse
0x08000000 anspringt und von dort der Bootloader zu Adresse 0x08010000 
springt.

Was mir jedoch nicht klar ist, ob der Sprung aus dem Bereich 0xFFFFFFF - 
0xFFFxxxx zu
Adresse 0x08000000 automatisch erfolgt, wenn der MC nicht auf den 
internen Bootloader von
ST gejumpert ist, oder vorab dieser Wert 0x8000000 irgendwo in der 
Start-Vektortabelle
eingetragen werden muss.

Bedeutet das, das ich noch eine Start-Adresse im  0xFFFFFFF -  0xFFFxxxx 
Adressrange
via ST-Link setzen muss damit der MC den Bootloader bei  0x08000000 
findet.

Ich hoffe mich soweit verständlich ausgedrückt zu haben, damit Ihr mir 
bei meinen
ersten ARM Projekt unter die Arme greifen könnt.

Vielen Dank für Eure Hilfe.

Markus
DL8MBY

[Markus W. (dl8mby)]

Nachtrag,

was sagen mir die angehängten Tabellen und Flow-Diagramme aus den 
STM32F04xxx
App Notes:

Siehe Anhang.

Kann der MC auch ohne Bootloader starten, oder ist immer ein BL zwingend 
erforderlich?
Was macht der WDT, wenn seine Zeit verstrichen ist (Reset oder Sprung 
zum RAM/ROM)?

Danke für jeden Sachdienlichen Hinweis.

Gruß
Markus

[Markus W. (dl8mby)]

Nachtrag #2,

kann es sein, dass die angehängte Darstellung, genau das ist, was ich 
suche?

Markus

[Tipp (Gast)]

Hallo Markus,

der STM32 hat einen Hersteller eigenen Bootloader. Der wird wie in dem 
Ablauf beschrieben per PIN nach Reset aktiviert.

Du nutzt aber einen eigenen Loader. Der ist für den uC ein ganz 
normales Programm. Für deinen eigenen Loader muss es eine Beschreibung 
geben, wie man in benutzt. Über deine Links bin ich folgendes gestoßen
http://www.amateurfunk-sulingen.de/forum/index.php?board=15;action=display;threadid=261;start=msg1471
Da steht etwas von 500ms Taste halten ...

[Markus W. (dl8mby)]

Hallo Tipp,

habe mich etwas durch die App-Note von ST gearbeitet und eigentlich per 
Zufall das Problem gelöst.

Unabhängig vom (USER-Bootloader) startet dieser ARM MC bei Adresse 
0x08000000, sofern er nicht durch die Ereignisse an diversen Pins (CAN, 
I2C, USB, UART ...)  und durch Bootmode-Jumper in einen anderen Flow 
abzweigt.

Mein Fehler bestand darin, dass der externe Bootloader im Projekt im dfu 
Mode zum MC über ein Programm von ST übertragen wird (Fileendung .dfu), 
ich aber via st-flash unter Linux arbeite.

Diese *.dfu Datei wird aus dem *.hex-Format über *.bin mittels eines 
Python Converter-Skripts erzeugt.

Mangels Wissen und Erfahrung  habe ich immer diese *.dfu Datei via 
st-flash zum MC übertragen und das Programm hat sich immer mit OK-Status 
beendet.

Da ich nun selber die Sourcen compilieren kann, habe ich bemerkt, dass 
auch ein  bootloader.bin File dabei erzeugt wird.

Als ich dieses File zum MC an die Adresse 0x08000000 übertragen habe, 
ist sofort alles reibungslos gegangen.

Das Gerät kommt nach dem Einschalten der Versorgung wieder von selber 
hoch und alles passt jetzt, zumindest auf den ersten Blick.

Wo ich mir noch nicht ganz sicher bin, das sind die Linker-Skripte, die 
ja für den 405/7 gebaut wurden und nicht für den 437/9.


Kann jemand mal drüber sehen und mir sagen ob die Einstellungen für 
einen STM32F439IV so in Ordnung sind.

Bootlader soll bei 0x08000000 und die FW bei 0x080100000 liegen.
Sind die Werte für RAM / ROM einfach auf 256k bzw 2048k zu setzen und 
die
Min-Stack-Size einfach von 0x400 auf 0x800 zu erhöhen.
Ferner habe ich Stack-End auf den Wert 0x20040000 (da 256kRAM verfügbar) 
gesetzt.

Danke für die Mühe schon mal vorab.

Markus
DL8MBY