Guten Abend zusammen,
ich hab heut mein F4 Discovery bekommen und gleich angesteckt.
Die Demo-Applikation lief sofort los (LED Blinken und Demo des
Beschleunigungssensors).
Ich hatte vor die GNU Toolchain unter Ubuntu zu verwenden, welche ich
bereits die Tage installiert hatte.
Zum Flashen war st-flash vorgesehen, das hab ich gerade frisch aus den
Quellen kompiliert.
Auf der ST Seite gibt es ja die Demosoftware als Quellcode zum
herunterladen. Dabei liegt auch ein fertiges Hexfile.
Dieses wollte ich probehalber mal mittels st-flash aufs Board spielen.
Folgendes Kommando hab ich benutzt:
1
st-flashwritedemo.hex0x8000000
wobei demo.hex das Demoprojekt von ST ist (ich habs nur umbenannt).
Das Flash-Tool lief einwandfrei durch (nachdem ich ihm Rechte zur
USB-Benutzung verpasst habe)
Seitdem ist das Board tot.
Keine LEDs leuchten (abgesehen von den roten Power LEDs). Auf
Tasterdruck wird auch nicht reagiert.
Was kann da falsch gelaufen sein?
Mein st-flash Aufruf scheint mir plausibel, ich hab ihn auch so im
Internet (unter anderem in einem ST-Tutorial) gefunden.
Die hex-Datei stammt von ST selbst.
Was kann da also nicht passen?
Viele Grüße!
Was sagt lsusb wenn du das Board ansteckst?
Ansonsten muss man sagen das dieses Board echt ziemlich empfindlich ist.
Der kleinsten Kurzschluss führt zum kompletten Hirntod. Ich habe selber
schon 1-2 Boards "zerschossen".
Auf dem Applikationsport nichts. Das bestätigt wohl, dass die Firmware
NICHT läuft. Leider hab ich vorher nicht nachgesehen wie sich der
Applikationsport anmeldet (als es noch ging).
Übrigens, weitere Flashversuche sind erfolglos:
Kann des wirklich sein dass ich mir so leicht was zerschieß? Hab das
Teil eigentlich sehr vorsichtig behandelt. Mein AVR Dragon (dem ja nicht
gerade Robustheit nachgesagt wird) musste schon ganz anderes erdulden...
Hat noch jemand eine Idee?
Jumper sind übrigens unverändert, beide gesteckt.
Viele Grüße!
Haro schrieb:> st-flash write demo.hex 0x8000000
st-flash schreibt direkt den Inhalt der Datei in den Flash, d.h. schön
das .hex Format so wie es ist... Du musst die Datei erst ins Binärformat
konvertieren, und die dann flashen, z.B.:
1
arm-none-eabi-objcopy -O binary demo.hex demo.bin
2
st-flash write demo.bin 0x08000000
Wenn st-util keine Verbindung herstellen kann, halte Reset gedrückt und
lasse genau in dem Moment los wo du st-util startest. Das genaue Timing
muss man üben. Bedanke dich bei ST für die enorme Qualität des ST-Link
sowie den Hardware-Bug in allen STM32, der das manchmal nötig macht (im
Gegensatz zu allen anderen Cortex-M* Controllern aller anderer
Hersteller).
>Device connected is: F4 device, id 0x10016413
Das Board meldet sich doch noch. Da ist nichts kaputt.
Dieser flash loader scheint zu spinnen.
Versuchs mal mit Windows und dem ST-Link Utility.
Du wirst sehen das das Board noch völlig intakt ist.
holger schrieb:> Versuchs mal mit Windows und dem ST-Link Utility.> Du wirst sehen das das Board noch völlig intakt ist.
Das heißt gar nix. Der STM32 kann durchgebrannt sein während das ST-Link
noch läuft. Das durch eine kaputte Firmware zu verursachen ist aber
nicht sehr wahrscheinlich.
Für die wichtigste Funktion des ST-Link Utility siehe Anhang; manchmal
will das Utility nicht während Texane st-link sehr wohl funktioniert,
und umgekehrt.
Das ST-Link Utility hat unter Windows die Funktion "Connect under
Reset". Damit kann man den Controller auch oft retten, wenn er zunächst
nicht mehr zu reagieren scheint.
Die Datei ist im Intel-Hex Format.
In meinem jugendlichen Leichtsinn dachte ich, ich könnte diese direkt
draufspielen (analog zum avrdude).
Wie auch immer, auch wenn die Datei das falsche Format hatte, deswegen
müsste sich doch der Prozessor trotzdem neu bespielen lassen.
Der JTAG-Coprozessor scheint zu laufen, auch die Verbindung zum "Main"
klappt anscheinend (laut st-util)
Haro schrieb:> @ DrSommer: das objcopy bringt leider nichts...Unable to recognise the> format of the input file `demo.hex'
Ok dann muss man dem noch ein bisschen auf die Sprünge helfen:
> Die Datei ist im Intel-Hex Format.> In meinem jugendlichen Leichtsinn dachte ich, ich könnte diese direkt> draufspielen (analog zum avrdude).
Leider nein, st-flash kann kein ihex einlesen...
Haro schrieb:> Der JTAG-Coprozessor scheint zu laufen, auch die Verbindung zum "Main"> klappt anscheinend (laut st-util)
Dann ist er nicht gegrillt, schonmal etwas :o)
Vielen Dank DrSommer, jetzt läuft wieder alles!
Naja, ich hätt mich eigentlich einlesen können, dann hätt ich gewusst
dass st-link kein iHex mag. Bin aber irgendwie davon ausgegangen, da ja
ST auch eins mit der Demosoftware ausliefert...
Aaaber: was ist denn da passiert?
Ich hab st-link meine iHex Datei gegeben. Diese wurde wahrscheinlich raw
eingelesen und geflasht. Dementsprechend ist der Prozessor Amok gelaufen
weil die Firmware natürlich nicht sinnvoll war.
Aber wieso konnte ich das iHex kein zweites mal flashen?
Wär noch interessant.
Wie auch immer, jetzt kommt der nächste Schritt: Demoprojekt selber
kompilieren :-)
Haro schrieb:> Bin aber irgendwie davon ausgegangen, da ja> ST auch eins mit der Demosoftware ausliefert...
ST hat ja auch nix mit st-link zu tun, das ist ein unabhängiges Open
Source Projekt.
Haro schrieb:> Ich hab st-link meine iHex Datei gegeben. Diese wurde wahrscheinlich raw> eingelesen und geflasht. Dementsprechend ist der Prozessor Amok gelaufen> weil die Firmware natürlich nicht sinnvoll war.
Ja.
> Aber wieso konnte ich das iHex kein zweites mal flashen?
Keine Ahnung, vermutlich zufällig auftretende Bugs in st-link, dem
ST-Link-Chip, dem Debug-Core im STM32...
Dr. Sommer schrieb:> ST hat ja auch nix mit st-link zu tun, das ist ein unabhängiges Open> Source Projekt.
Stimmt. Kam da durcheinand. Immerhin pflegen die sogar eine
Binärdistribution der GNU Toolchain. (Leider nicht für mein OS).
Die .bin ist ja wieder eine Binärdatei...
Was ist denn da alles drin? Ist das ne abgespeckte .elf?
Haro schrieb:> Stimmt. Kam da durcheinand. Immerhin pflegen die sogar eine> Binärdistribution der GNU Toolchain. (Leider nicht für mein OS).
Was?? wo??
> Die .bin ist ja wieder eine Binärdatei...> Was ist denn da alles drin? Ist das ne abgespeckte .elf?
Nee, das ist einfach nur eine Abfolge von Bytes die so 1:1 ins Flash
geschrieben werden. Ein .elf ist ein komplexes Format, welches solche
Bytefolgen, Symbolnamen, Debug-Informationen etc. enthalten kann. Daher
wird es vom Debugger GDB verwendet um mehr als nur Maschinencode
anzeigen zu können.
Das Problem hatte ich auch mal, weil ich sämtliche Pins von Port-A auf
Input gesetzt hatte und damit die Debug-Schnittstelle totgelegt habe.
Ich habe mich dann erinnert, dass es da noch ein Programmier-Programm
"STM32 ST-Link Utility" gibt.
http://www.st.com/web/en/catalog/tools/PF258168
Das Flashen ging aber erst auch nicht. Dann habe ich in Settings das
gewählt:
Target->Settings Connection Mode: Connect under Reset
Damit konnte ich dann den "guten" Code wieder flashen und ab da klappte
auch das Flashen und Debuggen in CooCox wieder.
Dr. Sommer schrieb:> Haro schrieb:>> Stimmt. Kam da durcheinand. Immerhin pflegen die sogar eine>> Binärdistribution der GNU Toolchain. (Leider nicht für mein OS).> Was?? wo??
Sorry, das war ARM. Habs durcheinandergeschmissen. Das wars, ich leg
mich auf die Couch :-)
Haro schrieb:> Sorry, das war ARM. Habs durcheinandergeschmissen. Das wars, ich leg> mich auf die Couch :-)https://launchpad.net/gcc-arm-embedded Meinst du die? Die ist für Linux,
Windows und sogar Mac OS X. Programmierst du auf einem iPad oder was...
Thread beobachten
Seitenaufteilung abschalten