Hallo.
Ich bin Neuling in Sachen Mikrocontroller und versuche mich daher
erstmal an einem bestehendem Projekt. Da der Ehrgeiz größer ist wenn man
anschließen auch was damit anfangen kann hab ich keine Demo Datei mit
blinkenden LED genommen, sondern ein zur Verfügung stehendes Projekt.
Erschwerend kommt hinzu, das ich unter Mac OS X arbeite und somit im
Terminal arbeiten muss. (Ich kann also kein WinAVR verwenden, das wohl
urspünglich für das Projekt genutzt wurde)
Mein Problem ist das ich den Attiny2313 nicht flashen kann. Nutze einen
avrisp mkii und die Kommunikation scheint zu funktionieren. Zumindest
antwortet der Mikrocontroller mit Device Signature etc.
Ich hatte erst versucht auf einem Steckbrett die Fuses zu schreiben, da
die aber für eine externen Quarz vorgesehen sind, war der
Mikrocontroller dann nicht mehr zu erreichen. Ich hab's dann mit einem
neuen in der finalen Schaltung versucht die einen Quarz enthält. Auch
der ist nach schreiben der Fuses aber nicht mehr erreichbar.
Meine Schlussfolgerung ist, dass man immer zuerst die Firmware schreiben
muss, und anschließen die Fuses, insbesondere wenn man mit dem nackten
Controller auf dem Steckbrett arbeitet. Ist das korrekt?
Ich habe dann, wieder mit einem neuen Mikrocontroller, versucht erst die
Firmware.hex auf den Chip zu brenne, leider funktionier aber auch das
nicht. Ich bekomme folgende Antwort
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
9
To disable this feature, specify the -D option.
10
avrdude: erasing chip
11
avrdude: reading input file "Firmware.hex"
12
avrdude: input file Firmware.hex auto detected as invalid format
13
avrdude: invalid input file format: -1
14
avrdude: read from file 'Firmware.hex' failed
15
16
avrdude: safemode: Fuses OK (H:FF, E:DF, L:64)
17
18
avrdude done. Thank you.
Google hat mich bisher nicht weiter gebracht. Es gibt diese
Fehlermeldung häufig ergänzt durch "no such file or directory", womit
der Fehler klar ist. Das ist hier aber nicht der Fall.
Was muss ich also machen um die *.hex auf den Controller zu bekommen,
und die Fuses richtig zu setzen, damit der Mikrocontroller läuft?
Wäre über Hilfe sehr dankbar.
vg Michael
Michael schrieb:> avrdude: input file Firmware.hex auto detected as invalid format
Und da muss man avrdude recht geben. Die Datei, die du als
'Firmware.hex' gepostet hast, ist ungültig und entspricht nicht dem
Format, das als 'Intel HEX' bekannt ist. Da stimmt also was in der
Entstehungsgeschichte dieser Datei nicht.
Michael schrieb:> Meine Schlussfolgerung ist, dass man immer zuerst die Firmware schreiben> muss, und anschließen die Fuses, insbesondere wenn man mit dem nackten> Controller auf dem Steckbrett arbeitet. Ist das korrekt?
Als Anfänger kann ich dir nur raten, zuerst einmal die Finger von den
Fuses zu lassen. Alle AVR Controller werden so ausgeliefert, das sie mit
dem internen RC Oszillator starten und meistens mit 1MHz Takt. Erst,
wenn du das Problem mit der Firmware gelöst hast, kannst du dich später
mal an den Fuses versuchen. Das Risiko, dich auszusperren, ist im Moment
noch zu hoch.
Matthias S. schrieb:> Und da muss man avrdude recht geben. Die Datei, die du als> 'Firmware.hex' gepostet hast, ist ungültig und entspricht nicht dem> Format, das als 'Intel HEX' bekannt ist.
Woran hast du das erkannt? Der Ersteller des Projekts muss die aber ja
auch irgendwie auf dem Controller bekommen haben.
Ich hätte den Code auch noch als *asm da. Was wären denn die korrekten
Befehle um den als intel hex zu kompilieren? Geht das mit dem avr gcc?
Das ist ebenfalls bei Crosspack mit drin was ja für Mac OS X den avrdude
liefert.
Ist es denn grundsätzlich so das man erst die *.hex flashed und dann die
Fuses brennt? Mich wundert das ich den Controller auch in der fertigen
Schaltung nicht ansprechen kann, obwohl dort ja ein Quarz vorhanden ist.
vg
Das Format von Intel HEX ist z.B. hier beschrieben:
https://de.wikipedia.org/wiki/Intel_HEX
Es beginnt auf jeden Fall mit einem Doppelpunkt. Dann kommen 4 Byte
Header, die Daten und dann 1 Byte Checksumme. Ganz am Ende dann EOF,
auch mit Checksumme. Die jeweilige Länge einer Datensatzzeile ist im
ersten Byte untergebracht, das könnte 0x01 ... 0xFF sein. Im angehängten
Beispiel ist es bis auf die letzte Datenzeile 0x10 für 16 Datenbytes.
Michael schrieb:> Mich wundert das ich den Controller auch in der fertigen> Schaltung nicht ansprechen kann,
In deinem Post oben hat er aber die Device Signature sowie das Löschen
nicht bemängelt, also kannst du ihn ansprechen.
Hallo,
ich nutze noch eine erweiterte Parameterübergabe, hier meine Ergänzung:
"-B 5 -U flash:w:<datei>.hex:a"
Zum einen läuft ein neuer attiny mit 1MHz RC Oszillator, Parameter -B
und zum Anderen kann das Programm avrdude das Dateiformat, bei -U
flash:w:<datei>.hex:a, selbst ermitteln.
Michael schrieb:> Der Ersteller des Projekts muss die aber ja> auch irgendwie auf dem Controller bekommen haben.
Dann poste mal nen Link darauf.
Das ist jedenfalls kein mir bekanntes Format (Hex, Bin, Elf, Srec).
Was für ein Fusetool ist das?
Das Format der Datei ist straight-hex, keine Ahnung wer so was
produziert.
Ich hab es mal in Intel-Hex umformatiert, kann aber high und low Byte
vertauscht sein.
Michael schrieb:> Was wären denn die korrekten> Befehle um den als intel hex zu kompilieren? Geht das mit dem avr gcc?> Das ist ebenfalls bei Crosspack mit drin was ja für Mac OS X den avrdude> liefert.
Hier mal ein makefile, was für mich gut funktioniert - vorsicht,
Fuse-Einstellungen sind definitiv falsch/passen nicht zu deinem Projekt
Verwendest du eine IDE?
Michael schrieb:> Ich hätte den Code auch noch als *asm da. Was wären denn die korrekten> Befehle um den als intel hex zu kompilieren? Geht das mit dem avr gcc?
Nö.
Der GCC benutzt GAS und der ist nicht mit dem Atmel Assembler
kompatibel.
Das Format der "Firmware.hex", aus dem Eröffnungspost, kann der AVRDUDE
eigentlich lesen, vielleicht wurde es sogar damit geschrieben (ein
programmierter Käfer ausgelesen).
Der Suffix dafür ist "h" wie "Hex", nicht "i" wie "Intel-Hex".
also Programmaufruf mit -U flash:w:Firmware.hex:h
Anscheinend hat der AVRDUDE hin und wieder Probleme, das Format der
Datei an der Endung oder am Dateiinhalt korrekt zu erkennen.
Beitrag "Re: AVR8 Burn-O-Mat läuft nicht mit Java 9"
Dann ist es sicherer, ihn auf das Dateiformat explizit hinzuweisen.
HildeK schrieb:> Michael schrieb:>> Mich wundert das ich den Controller auch in der fertigen>> Schaltung nicht ansprechen kann,>> In deinem Post oben hat er aber die Device Signature sowie das Löschen> nicht bemängelt, also kannst du ihn ansprechen.
Das war ja bevor ich versucht hatte die Fuses zu schreiben. Hab mich
vielleicht unglücklich ausgedrückt.
Peter D. schrieb:> Dann poste mal nen Link darauf.> Das ist jedenfalls kein mir bekanntes Format (Hex, Bin, Elf, Srec).>> Was für ein Fusetool ist das?
Hier der Link
http://www.digital-enlightenment.de/mux.htm
Eigentlich wollte hatte ich versucht das mit dem Terminal zu machen.
Habe dann auch noch das Tool AVRFuses probiert. DAs ändert aber nichts.
R. M. schrieb:> Anscheinend hat der AVRDUDE hin und wieder Probleme, das Format der> Datei an der Endung oder am Dateiinhalt korrekt zu erkennen.
Ok. Dann probier ich das mal als erstes. Wenn das auch nicht
funktioniert geh ich nochmal an die Vorschläge von Dieter Werner und Der
Dude aka. White Russian ran. Da hätte ich jetzt sonst Befürchtungen das
mit den Fuses wieder was nicht hin haut.
R. M. schrieb:> Der Suffix dafür ist "h" wie "Hex", nicht "i" wie "Intel-Hex".> also Programmaufruf mit -U flash:w:Firmware.hex:h
So, das hat leider auch nicht funktioniert.
Dann bekomme ich die Ausgabe
1
avrdude: AVR device initialized and ready to accept instructions
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
7
To disable this feature, specify the -D option.
8
avrdude: erasing chip
9
avrdude: reading input file "Firmware.hex"
10
avrdude: fileio: invalid operation=0
11
avrdude: read from file 'Firmware.hex' failed
12
13
avrdude: safemode: Fuses OK (H:FF, E:DF, L:64)
14
15
avrdude done. Thank you.
Wenn keiner weitere Ideen hat würde ich mich mal an den Vorschlag von
Dieter Werner (@dds5) machen.
Was meinst du denn mit
Dieter W. schrieb:> kann aber high und low Byte> vertauscht sein.
Was meinst die I/O Bytes? Oder worauf beziehst du das?
Wie hast du das *.hex-file denn umgewandelt?
Michael schrieb:> So, das hat leider auch nicht funktioniert.
Logisch, Du willst ja auch sicher die atmel2313.HEX flashen und nicht
die Firmware.hex.
wendelsberg
Thread beobachten
Seitenaufteilung abschalten