Hi,
Nachdem ich mich enschlossen hab die 8 bitter AVR hinter mir zu lassen,
bin ich beim ARM STM32F407 gelandet. Ich hab mir das STM32-E407 Board
von Olimex und einen ST-Link/V2 Programmer zugelegt und kämpfe jetzt
damit ein funktionierendes Beispiel zum laufen zu bekommen ... fürs
erste mal das onboard LED blinken lassen.
Nachdem ich mich eine weile eingelesen hab, ist soweit alles
installiert. Ich hab die GNU Tools for ARM Embedded Processors [1], die
Programmier-SW von [2] und die "STM32F4xx DSP and Standard Peripherals
Library" von [3] genommen. Ich hab auch schon erfolgreich die Toolchain
in Netbeans konfiguriert und kann daraus kompilieren, linken und das
Programm auf das Board spielen.
Doch leider tut sich nichts am Board :-(
Was mir noch unklar ist, und ich aus der AVR Welt auch nicht kenne, ist
die verwendung der Files stm32_flash.ld und startup_stm32f40xx.S. Das
stm32_flash.ld ist ein link-script das ich dem Linker via
"-Tstm32_flash.ld" mit auf dem Weg gebe - Das hab ich jetzt mal aus der
STM Library übernommen - weiss aber nicht ob das passt, siehe Anhang.
Auf dem Board ist der Controller STM32F407ZGT6 verbaut.
Wie ich das startup_stm32f40xx.S einbinden muss ist mir noch nicht klar,
vielleicht kann mir da wer weiterhelfen? oder vielleicht brauch ichs
auch nicht?
In weitere Folge möchte ich das Netzwerk ansprechen und UDP Telegramme
senden und empfangen. Vielleicht hat das jemand ein einfaches Beispiel
im Makefile-Style, das wär echt Spitze.
Hier mein Code:
Markus Manninger schrieb:> und kämpfe jetzt> damit ein funktionierendes Beispiel zum laufen zu bekommen ...
O je.
Du hast m.E. völlig falsch angefangen.
Als allererstes solltest du gucken, ob du für diesen ST-Link ein
standalone Brennprogramm hast bzw. beschaffen kannst. Wenn ja, dann guck
dir an, wie das funktioniert und mach dich damit vertraut. Wenn nicht,
dann würde ich dir schlichtweg zum eingebauten Bootlader raten, den man
normalerweise mit einem STM- oder Erfos-Brennprogramm o.ä. benutzen
kann. Ob dein Olimex-Board das hergibt, weiß ich aber nicht. Fakt ist,
daß du erstmal er hinbekommen solltest, deinen µC zu löschen, zu
programmieren, Verify durchzuführen usw.
Sodann solltest du dir das kurzgefaßte Usermanual des Chips (jaja, ich
weiß) reinziehen. Dazu gehört irgendwann auch das original-ARM-Manual
zur CPU, denn das lassen die meisten Hersteller gern weg.
Als nächstes solltest du dir ein Startup-File für die betreffende
Familie genauer anschauen, um draus zu lernen, wie der ganze Prozessor
überhaupt angelassen werden muß. Du hast bislang nen Trabbi programmiert
und nun mußt du dich in ne Boing747 einarbeiten. Die hat wesentlich mehr
Knöpfe im Cockpit.
Ich mache das so, daß ich mir den Startup-Code selber schreibe, ebenso
ein Headerfile, das alles aufführt, was ich vom Startupcode exportiere.
Ähnlich halte ich es mit den Hardwaredeklarationen. Die im Internet
erhältlichen sind nämlich meistens so vergurkt, daß man keinen
ordentlichen Bezug zum HW-Manual mehr hat. Da ist es weitaus besser und
sicherer, die echten Angaben aus dem HW-Manual zu kopieren und daraus
sich seine eigenen Deklarationen zu machen.
Dann erst ist das Schreiben von C angesagt - und nimm lieber keines der
üblicherweise doofen Demoprogramme, sondern fange selbst und richtig an
- mit was Eigenem.
W.S.
W.S. schrieb:> Du hast m.E. völlig falsch angefangen.
Ja wie soll man denn sonst anfangen? Man besorgt sich ein
Entwicklerboard und einen Programmer und muss sich halt einarbeiten.
> Als allererstes solltest du gucken, ob du für diesen ST-Link ein> standalone Brennprogramm hast bzw. beschaffen kannst. Wenn ja, dann guck> dir an, wie das funktioniert und mach dich damit vertraut. Wenn nicht,> dann würde ich dir schlichtweg zum eingebauten Bootlader raten, den man> normalerweise mit einem STM- oder Erfos-Brennprogramm o.ä. benutzen> kann. Ob dein Olimex-Board das hergibt, weiß ich aber nicht. Fakt ist,> daß du erstmal er hinbekommen solltest, deinen µC zu löschen, zu> programmieren, Verify durchzuführen usw.
Also das stlink ist ein "standalone Brennprogramm" und ich kann ja schon
flash auslesen und schreiben ... siehe Ausgabe von st-flash. Und mit dem
ST-LINK/V2 sollte ich alles haben um mein Programm auf den Controller zu
bekommen inkl. Debugmöglichkeiten.
> Sodann solltest du dir das kurzgefaßte Usermanual des Chips (jaja, ich> weiß) reinziehen. Dazu gehört irgendwann auch das original-ARM-Manual> zur CPU, denn das lassen die meisten Hersteller gern weg.
Jop, das mach ich gerade. Das ARM Manual hab ich mir aber noch nicht
angeschaut.
> Als nächstes solltest du dir ein Startup-File für die betreffende> Familie genauer anschauen, um draus zu lernen, wie der ganze Prozessor> überhaupt angelassen werden muß. Du hast bislang nen Trabbi programmiert> und nun mußt du dich in ne Boing747 einarbeiten. Die hat wesentlich mehr> Knöpfe im Cockpit.
Aber wozu ist ein Startup-File gut bzw. wie muss ich es in die Toolchain
einbauen???
Ich hab jetzt ein startup-file aus dem Beispielcodes von Olimex, direkt
für dieses Board, das sollte doch mal fürs erste funktionieren.
Nachtrag - Hier hab ich was gefunden:
http://www.bravegnu.org/gnu-eprog/c-startup.html
lG,
Max
Kann jemand sagen ob der Code grundsätzlich funktionieren sollte?
Anbei auch noch ein object-dump vom binary, da fällt mir nur auf dass
die start address 0x00000000, doch der Flash sollte doch bei 0x08000000
anfangen, oder?
W.S hat eigene Ansichten - die ihm gegönnt seien - aber Du solltest
Dich dadurch nicht verwirren lassen.
Als Anfänger den Startup-Code und alles andere selbst schreiben
zu wollen ist vermessen. Das führt nur zu Frust.
Ein einfaches, fertiges Blinkprogramm als Basis zu nehmen ist durchaus
der richtige Ansatz.
Dass die Startadresse Deines Codes 0x0 ist, wird wahrscheinlich heissen,
dass er zur Ausführung aus dem RAM gelinkt ist (ich kenne die
STM32 Memory Map jetzt nicht auswendig).
Du kannst auch mal einen Blick in die libopencm3 werfen, da sind
einige Beispielprogrämmchen dabei. STM32F407 wird auch unterstützt.
Wenn Du eine Toolchain installiert hast, hast Du innerhalb einer
halben Stunde ein lauffähiges Programm.
Sich mit den ARM Manuals zu beschäftigen, hat erst einen Sinn,
wenn Du das Nötige aus dem STM32-Refman (hauptsächlich
Peripheriegeschichten.Memory Map) verstanden hast.
Der Startup-Code dient dazu, den den Chip so weit zu initialisieren,
dass
die C-main Funktion ein lauffähiges Environment vorfindet.
Schnurzz
Hallo Max,
>Hast du kein Windows? Mit einer fertige IDE wie CoIde oder emblocks tust>du dich wesentlich leichter!
musst Du auch nicht allzu ernst nehmen.
Du bist näher am Erfolg, als Du glaubst. Es sind nur Kleinigkeiten,
die fehlen.
>Doch leider tut sich nichts am Board :-(
Weiss nicht wie's bei den F407 Boards ist, aber bei F0x Boards
gibt's Jumper, die bestimmen, ob der Chip aus dem Boot-ROM, Flash, oder
RAM bootet.
Schau' mal diesbez. nach.
Keine Sorge, ich nehme eh nicht alles so ernst. Nachdem ich die
Toolchain (compiler, linker, libraries & programmer) soweit am laufen
hab, glaub/hoffe ich auch nicht dass ich so weit davon entfernt bin ...
aber woran scheiterts noch?
Ich hab auch noch ein STM32F4 Discovery Board hier, und ein
funktionierendes Blink Beispiel mit Makefile gefunden. Das kann ich
problemlos übersetzten und aufs Board spielen und es läuft auch.
Ich denke ich brauch mal ein passenden startup file und link script
Zunächst mal macht mich das hier stutzig:
> Attempting to write 104404 (0x197d4) bytes to stm32 address: 134217728
(0x8000000)
Also 100kB für eine Blink LED? Da stimmt etwas nicht.
Der Linker erzeugt dir eine Datei im ELF Format. st-flash erwartet
soweit ich weiß ein .bin file. Das Tool "arm-none-eabi-objcopy" kann die
aus der elf Datei erzeugen.
Das mit der Adresse stimmt schon. Im Manual unter Kap. 2.4 (Boot
configuration) kannst du das nachlesen.
In dem gepostetem Startcode wird die Funktion "SystemInit" aufgerufen.
Das ist auch üblich, nur kann ich die bei dir nicht entdecken. In deinem
"Dump" steht etwas von SystemInit mit einer Adresse im RAM und der Länge
0.
Ich würde mich gar nicht weiter mit dem Code aufhalten. Das hier
Beitrag "STM32F4 discovery unter Linux"
(Anhang im letzten Post) sieht doch ganz gut aus. Vor allem das
"IO_Toggle" Beispiel.
schnurzz schrieb:>>Doch leider tut sich nichts am Board :-(>> Weiss nicht wie's bei den F407 Boards ist, aber bei F0x Boards> gibt's Jumper, die bestimmen, ob der Chip aus dem Boot-ROM, Flash, oder> RAM bootet.>> Schau' mal diesbez. nach.
Stimmt laut Doku [1] 6.2.12 gibts den Jumper auf dem Board. Im moment
scheint es vom User Flash Memory zu booten ... umjumpern bringt leider
nix.
[1]
https://www.olimex.com/Products/ARM/ST/STM32-E407/resources/STM32-E407.pdf
Stefan schrieb:> Zunächst mal macht mich das hier stutzig:>>> Attempting to write 104404 (0x197d4) bytes to stm32 address: 134217728> (0x8000000)>> Also 100kB für eine Blink LED? Da stimmt etwas nicht.> Der Linker erzeugt dir eine Datei im ELF Format. st-flash erwartet> soweit ich weiß ein .bin file. Das Tool "arm-none-eabi-objcopy" kann die> aus der elf Datei erzeugen.
Das File erzeugt mit der Linker:
1
$ file dist/Debug/ARM-Linux-x86/blink-led
2
dist/Debug/ARM-Linux-x86/blink-led: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped
Das ist mir auch schon recht groß vorgekommen. generiere ich ein binary
via:
Schaut die Sache schon besser aus, funktioniert aber trotzdem noch
nicht.
> Das mit der Adresse stimmt schon. Im Manual unter Kap. 2.4 (Boot> configuration) kannst du das nachlesen.>> In dem gepostetem Startcode wird die Funktion "SystemInit" aufgerufen.> Das ist auch üblich, nur kann ich die bei dir nicht entdecken. In deinem> "Dump" steht etwas von SystemInit mit einer Adresse im RAM und der Länge> 0.
Der Startcode sollte doch für alle STM32F407 MCs gehen, oder ... dann
muss sich doch ein funktionierender finden lassen.
> Ich würde mich gar nicht weiter mit dem Code aufhalten. Das hier> Beitrag "STM32F4 discovery unter Linux"> (Anhang im letzten Post) sieht doch ganz gut aus. Vor allem das> "IO_Toggle" Beispiel.
Das IO_Toggle kann ich kompilieren und auf das Discovery spielen ... das
funktioniert alles! Sollte ich mal den Startcode in mein Projekt
einbinden?
Markus Manninger schrieb:> Ja wie soll man denn sonst anfangen?
SOLL? _SOLL???_
Nein, kann.
Wie jung bist du und wieviel Erfahrung hast du? Das spielt ne Rolle. Je
jünger, desto schneller und besser lernt man, je älter, desto mehr
Erfahrung hat man so auf der Hinterhand.
Also, ich beschreibe mal, wie ich mit nem STM32 angefangen habe:
Zu allererst hatte ich mir vom Standpersonal auf der Embedded in
Nürnberg ne Menge ganz toller Sachen erzählen lassen, die STM32 sind ja
SOO grandios, daß es einen glatt umhaut. Ähemm.. naja.
Dann hatte mir einer von denen so einen STM32-Primer in die Hand
gedrückt und gemeint "Iss gaaaaanz toll, nehmse ma und seinse
glücklich".
Nun, die diversen inzwischen verfügbaren STM32-Primer sind wirklich ne
nette Spielerei und die Entwicklungsumgebung RIDE7 nebst GCC ist auch
durchaus benutzbar. Aber das OS dieser Primer (Circle-OS) fand ich
grauenvoll - und es ist wie alles in der Szene lausig dokumentiert.
Also hab ich das Teil weggepackt, mich mal in das (damalige) Angebot von
ST vertieft und mir den STM32F103ZET6 herausgesucht. 1..3 Muster davon
sind keine Herausforderung.
Dann hab ich mir das zugehörige Manual durchgeackert.
Dann hab ich mir ein eigenes Eval-Board mit diesem µC ausgedacht,
ge-layoutet (oh deutsche Sprache..) und anfertigen lassen. Dann
bestückt, mir einen Adapter für die serielle Schnittstelle gemacht - tja
und dann angefangen, mir meine eigene Firmware zu schreiben.
Irgendwann später hab ich gemerkt, daß ich noch ne Leitung auf dem Board
vergessen hatte, also mit 0.15 CuL nachgesetzt.
Zum Entwickeln nehme ich eigentlich immer meinen eigenen Editor, an den
ich mich gewöhnt habe und zum Übersetzen schreibe ich mir ne simple
Batch-Datei. Da bin ich völlig unabhängig von den Befindlichkeiten
diversr IDE's und werde von sowas auch nicht eingeengt. Und heutzutage
in der Ära von gigahertzschnellen Vierkernern braucht man das partielle
Compilieren a la make auch nicht mehr, da reicht es aus, immer gleich
alles jedesmal durchzuziehen, also immer ein komplettes build machen. Ob
das nun 0.5 Sekunden oder stolze 4 Sekunden dauert, ist MIR egal.
Zum Brennen nehme ich schlichtweg den eingebauten Bootlader, der reicht
völlig aus. Debuggen? Was ist das? Viele Leute wissen nicht, was sie
schreiben und hängen dann stundenlang am Debugger, weil sie nicht denken
können sondern sehen müssen. Dabei ist der Debugger für die
eigentlichen Probleme völlig nutzlos. Ich denke da grad an sowas wie
den CDC USB Treiber, wo man schon wegen der Zeitbegrenzungen mit nem
Debugger garnix erreichen kann. Da ist ein in den Code geschriebener
post morte dump viel nützlicher.
Ach ja, so nebenbei hatte ich auf das Board auch noch ein CPLD mit
draufgesetzt und damit ne Ansteuerung für ein TFT Display gemacht, denn
sowas hat der STM nicht eingebaut.
So hat das mal ganz konkret bei mir ausgesehen. Allerdings neige ich
durch die mit dem STM32 gemachten Erfahrungen inzwischen mehr zu NXP,
die sind m.E. deutlich besser und man kann manchmal sogar mit denen
reden. Obendrein merkt man bei den Manuals von ST, daß dort laber- und
schwatzsüchtige Franzosen und Italiener am Werke waren. Viele Worte,
jaja, sehr viele, aber nach den benötigten Informationen sucht man sich
nen Wolf.
So, dies ist ne Herangehensweise, die man wählen KANN - gründlich,
aber eher weniger für künftige Überflieger geeignet. Wie DU es in
deinem Leben halten willst, mußt du selber dir erarbeiten.
W.S.
@W.S.:
Du hast natürlich recht, so kann ma es auch machen ... aber bei den
Angeboten an fertigen Boards zahlt es sich meiner Meinung nach nicht aus
was eigenes zu entwerfen, zumindest nicht zum Entwickeln.
Ich bin ein 33 jähriger Telematikstudent und sollte also schon noch
etwas Platz in meinem Hirn für Neues haben :-)
Nachdem ich beim AVR und externem Speicher an seine Grenzen gestoßen
bin, siehe [1], hab ich mich für die STM32er Familie entschlossen und
mir das oben genannte Board von Olimex entschieden. Debuggen tu ich
grunsätzlich auch nur, indem ich Debuginfos rausschreibe, dennoch wollte
ich mir die Möglichkeit offen lassen, richtig zu debuggen und hab mir
das ST-LINKv2 gegönnt.
Früher hatte ich auch alles im Emacs programmiert, aber mittlerweile hab
ich mich an Netbeans gewöhnt und eine IDE hat schon ihre Vorteile.
[1] Beitrag "Wieviel externes SRAM ist möglich"
Markus Manninger schrieb:> so kann ma es auch machen ...
Die eigentliche Frage ist, WAS du damit machen willst.
Ich mache sowas mit dem Ziel, später so einen Chip auch tatsächlich in
einem meiner Geräte zu verbauen (oder eben nicht) um damit meine
Brötchen zu verdienen. Da habe ich für irgendein fertiges Evalboard
keine wirkliche Verwendung, denn früher oder später muß ich ja sowieso
den Chip in eine eigene LP setzen. Dann also lieber früher als später,
da erspart man sich ein spätes "AufDieNaseFallen" und ersetzt es durch
ein früheres mit dem Evalboard, wo es noch keinen größeren Schaden
gegeben hat.
Markus Manninger schrieb:> aber bei den> Angeboten an fertigen Boards zahlt es sich meiner Meinung nach nicht aus> was eigenes zu entwerfen, zumindest nicht zum Entwickeln.
Hä? WAS entwickeln? Gerade zum Entwickeln muß man es selbst tun oder man
wird arm dabei. Ich sehe jedes Jahr auf der Embedded massenweise Stände,
wo grandiose Ing-Büros noch grandiosere selbst entwickelte µC-Boards
feilbieten und dafür eine Anwendung suchen. Sorry, aber die Anwendung
sucht sich das dazu passende µC-Board und nicht umgekehrt - und was zur
Anwendung paßt, weiß nur ich und nicht der Hansel auf dem Messestand.
Also, fertige Eval-Boards sind ne Art Spielzeuge und lediglich dazu
geeignet, den betreffenden µC näher kennen zu lernen - wenn man das
will. Wer für's Board noch ne fertige IDE und fertige Eval-Demo-Apps
haben will, der lernt den Chip damit nicht kennen.
Lade dir mal die Lernbetty hier aus der Codesammlung herunter. Mal
abgesehen davon, daß das Teil zwar ältlich ist (ARM7TDMI) ist es
spottbillig und man kann immer noch was draus lernen für den
ARM-Einstieg. Ja, es sind dort auch vorgekaute Apps dabei, damit man
sehen kann, wie man auch auf nem µC eine Trennung zwischen einer Art
Minimal-Betriebssystem und Anwendungen schreiben kann. Darüber hinaus
zeigt die Lernbetty aber eben auch, wie man einen µC programmiert
kriegt, ohne sich auf irgendeine IDE festlegen zu müssen. Zumindest
lernt man, die eigentliche Musike (Compiler, Assembler, Linker usw.)
selber aufzurufen - mit oder ohne Makefile je nach Gusto.
Markus Manninger schrieb:> Ich bin ein 33 jähriger Telematikstudent
Na, dann spute dich mal! Ich war mit 26 schon Entwicklungs-Ing in ner
Firma und heutzutage guckt man schon scheel auf Leute, die erst mit
Mitte 30 ihren ersten Industrie-Job suchen.
W.S.
Markus Manninger schrieb:> Das IO_Toggle kann ich kompilieren und auf das Discovery spielen ... das> funktioniert alles! Sollte ich mal den Startcode in mein Projekt> einbinden?
Der Startcode sieht gut aus. Du könntest das Linkerscript gegen eins
tauschen das den CCM unterstützt.
Das ganze Projekt ist meiner Ansicht nach zu verbastelt. Dieses
SystemInit() aktiviert z.B. die PLL. Das fehlt hier, der Controller
läuft damit mit seinenm 8MHz RC Oszillator.
Linkerfehler wegen fehlenden sbrk, close, ... kommen meist daher
zustande weil irgendeine Funktion aus der libc aufgerufen wird die für
Mikrocontroller nicht implementiert/angepasst wurde und die nun
Funktionen erwarten die ein Betriebssystem wie Linux bietet. printf()
verursacht z.B. solche Fehler.
Es gibt durchaus Umgebungen wo printf() verwendet werden kann. Das nennt
sich dann "semihosting". Die Ausgaben gehen dann an den Debugger oder
den UART. Atollic und LPCxpresso können das. Spielt hier aber keine
Rolle.
Mein Vorschlag:
Wenn du nicht mit Makefiles arbeiten willst dann nimm das IO_Toggle
Beispiel und sieh dir die Ausgaben von "make" an. Oder das Makefile
selbst. Die Dateien die dabei übersetzt werden brauchst du.
Das dürfte etwa diese sein:
main.c
startup_stm32f40xx.S
system_stm32f4xx.c
stm32f4xx_it.c
stm32f4xx_gpio.c
stm32f4xx_rcc.c
Und natürlich das Linkerscript. Des Weiteren folgende Konstanten:
USE_STDPERIPH_DRIVER
STM32F40XX
HSE_VALUE=8000000
Die sollten dem GCC mit "-D" übergeben werden. Also "gcc -DSTM32F40XX
-D...". Sonst macht die vermutlich die Stdlib von ST Ärger. Der HSE Wert
ist die Quarzfrequenz. Wenn du eine andere verwendest mußt du das
natürlich hier anpassen aber auch die system_stm32f4xx.c ändern (mind.
PLL_M, PLL_N).
Moin,
ich habe noch nicht mit ARM gearbeitet, daher kann ich nur
extrapolieren...
Markus Manninger schrieb:> Das ist mir auch schon recht groß vorgekommen. generiere ich ein binary> via:$ arm-none-eabi-objcopy -O binary dist/Debug/ARM-Linux-x86/blink-led> dist/Debug/ARM-Linux-x86/blink-led.bin> $ file dist/Debug/ARM-Linux-x86/blink-led.bin> dist/Debug/ARM-Linux-x86/blink-led.bin: 8086 relocatable (Microsoft)
Da kommt es mir komisch vor, dass das ein x86/8086 relocatable sein
soll. Eigentlich hätte ich da irgendwas mit ARM erwartet. Kann aber
natürlich sein, dass 'file' das nicht unterscheiden kann.
Markus Manninger schrieb:> Ich hab in meinem Linkerscript folgende Zeilen aubauen müssen, damit ich> die undefined references wegbekommen: __exidx_start = .;> __exidx_end = .;> _exit = .;> _sbrk = .;> _kill = .;> _getpid = .;> _write = .;> _close = .;> _fstat = .;> _isatty = .;> _lseek = .;> _read = .;>> _sidata = .;> _sdata = .;> _edata = .;> _sbss = .;> _ebss = .;> SystemInit = .;> _estack = .;> _init = .;>> War das vielleicht die falsche Methode?
Ja, ziemlich sicher. Undefined reference bedeutet: Der Linker findet die
entsprechende Funktion nicht. Ich kann nicht erkennen, dass du dem
Linker mit deinem Linker-Script irgendwie gesagt hast, wo er die
Funktionen findet.
Vermutilch fehlen die Funktionen in deinem Programm wirklich, und daher
läuft der Prozessor auch nicht so wie erwartet.
MfG, Arno
Sodala, hier mal ein komplettes Beispiel, ausgehende von dem IO_Toggle
Bsp des Disovery, inkl. Makefile mit folgendem Inhalt:
1
main.c
2
Makefile
3
startup_stm32f4xx.s
4
stm32f4xx_conf.h
5
stm32f4xx_it.c
6
stm32f4xx_it.h
7
stm32_flash.ld
8
system_stm32f4xx.c
Ich kanns kompilieren und mit "make flash" auf das olimex board spielen
... doch leider tut sich noch immer nix.
Wo wird denn definiert, wo das binary landet?
Müsste schon im stm32_flash.ld sein, oder? Nachdem in diesem Linker
Script die .text Section nach "> FLASH" geht, sollte mein Programm im
User Flash ab 0x08000000 landen ... hab ich das so richtig
interpretiert?
Nur damit ich weiss wie ich die Jumper auf meinem Board stecken muss
Bei läuft das Programm auf einem STM32F4Discovery Board.
Ich habe einige Dateien in den Projektordner kopiert und das Makefile
etwas angepasst. Damit gibt es keine externen Abhängigkeiten.
Geflasht habe ich mit
st-flash write LED_Blink.bin 0x8000000
Nach einem manuellen Reset fing die LED an PD13 an zu blinken.
Hat der Quarz auf deinem Board denn 8MHz? Ich verbaue gerne welche mit
12MHz da es die in kleineren Gehäusen gibt.
Ansonsten sieh dir nochmal die Jumper an. Die BOOTx gehören beide auf 0.
Kann ja nicht mehr viel sein.
Hallo Stefan,
Erstmal danke für deine Bemühungen, hast du auch das STM32-E407 Board
von Olimex?
Ich kann alles sauber kompilieren und aufs Board spielen ... blinken tut
aber leider noch immer nix. Auch nach einem Reset nicht. Die Jumper sind
beide auf B00_0 und B01_0 gesteckt, sollte also vom Flash starten.
Auf dem Discovery Board funktioniert das Programm!
Ja, das Olimex Board läuft mit 12MHz, hab dazu auch schon einen Patch
[1] fürs system_stm32f4xx.c gefunden ... leider kann ich ihn aber nicht
einspielen.
Nein, kein Olimex. Mein F4 Board mit 12MHz Quarz ist im verbaut und im
Einsatz, das Pflücke ich jetzt nicht auseinander ;).
Da sind verschiedene Versionen dieser Datei im Umlauf. Es geht aber nur
um das PLL_M. Anstelle von 8 muß da 12 stehen. Wenn das nicht passt
können mehrere Dinge passieren:
1. Quarz ist "langsamer" -> Programm läuft langsamer.
2.Quarz ist "schneller"
a) -> µC wird übertaktet und hängt.
b) -> PLL rastet nicht und Programm hängt in Endlosschleife.
Ich habe meine Version mal angehängt. Auf dem Discovery blinkt die LED
damit etwas langsamer.
Ups, stimmt, du hast ja ein Discovery Board. Das hatte ich gelesen aber
nicht weiter verarbeitet. Jetzt sehe ich auch dein Problem ;).
Auf die Gefahr hin daß du es schon erwähnt hast: Gibt es denn irgendein
Beispiel von Olimex das auf dem Board läuft? Weitere LEDs?
Jop, hab beide Boards und das LED Blinkbeispiel funktioniert nur am
Discovery.
Am Olimex Board hab ich nur eine LED, die auf GPIO 13 hängt, dort geht
aber leider nix. Ich hab auch keine anderen Beispiele die funktionieren.
Für die Beispiele von Olimex müsste man die IAR Embedded Workbench
installieren ... das wollte ich vermeiden.
Vom code her funktioniert das Blink Bsp ja und laut [1] hängt das User
LED auch auf GPIO 13. Es kann doch also nur mehr sein, dass das Programm
gar nicht ausgeführt wird, aus welchem Grund auch immer.
Also super wär ein komplettes Beispiel mit Linkerscript und startup
file, das bei jemanden auf dem Olimex Board STM32-E407 läuft!
[1]
https://www.olimex.com/Products/ARM/ST/STM32-E407/resources/STM32-E407_sch.pdf
Bin für jeden Tip dankbar!
lG,
Max
Juhuuu ... es funktioniert ... kaum macht man's richtig. Da hab ich mich
doch wirklich beim Port vertan, so ein blöder Fehler.
Danke auf jeden Fall für die unterstützung.
Jetzt werd ich mich mal nach einem geeigenten TCP/IP Stack umschaun und
versuchen den zum laufen zu bekommen!
Hi,
falls du Beispiele zum STM32, insbesondere dem F4 suchst, kannst du auch
mal bei http://mikrocontroller.bplaced.net/ vorbeischauen. Dort gibt es
exzellente Beispiele, unter anderem direkt lauffähige Projekte für
Ethernet. Verwendet wird die CooCox IDE, die ich gerade für die
Verwendung der ST Libraries dir auch nur ans Herz legen kann.
Vereinfacht das Leben enorm.
Liebe Grüße,
Jan
Ein Betriebssystem wird in den genannten Beispielen nicht verwendet.
Zum Chip: Ohne das jetzt im Detail überprüft zu haben, dürfte nichts
gegen die Verwendung des Micrel Chips sprechen. Schließlich ist die
Schnittstelle identisch (RMII oder MII).
Thread beobachten
Seitenaufteilung abschalten