Hi,
ich wechsel gerade meine komplette Ungebung von Windows zu Ubuntu.
- Bauen klappt
- flashen (hex) klappt
- flashen (eep) klappt scheinbar nicht:
jedenfalls kommen die Daten obgleich einer ok Meldung im Terminal
nicht auf dem Chip an (die eep auf nen Usb-Stick und mit dem alten
Windows geflasht brigt erfolg.
Also wo liegt der Fehler?
an /dev/ttyUSB0 hängt ein
"mySmartUSB light"
Firmware-Version: 1.16.1932
Firmware-Typ: STK500 kompatibel
[Stromversorgung beim Brennen aktiv: ja (unter Windows); 5V]
Controller: ATmega88
Grüße David
PS-Terminal-Response:
Kann mir keiner helfen, damit ich die Windows-Kisten endlich in die
ewigen Jagdgründe schicken kann?
Ich meine das eep Unix-->Windows-->flashen kann ja nicht so kompliziert
sein, wenn der Rest geht ;(
Du hast dabei einige Fragen nicht beantwortet:
1. Klappt es nur aus CMake nicht oder auch aus dem normalen Terminal
nicht
2. Wie hast du verifiziert, dass es nicht klappt?
AbcAbc schrieb:> Du hast dabei einige Fragen nicht beantwortet:> 1. Klappt es nur aus CMake nicht oder auch aus dem normalen Terminal> nicht> 2. Wie hast du verifiziert, dass es nicht klappt?
Der Befehl zum flashen des eep unterscheidet sich ja nur an einer Stelle
von jenem, der das Hex verarbeitet.
Ich kann es sehen, denn ich habe eine Display angeschlossen, dass einen
Eeprom Wert anzeigt.
Normal steht dort 1600 und derzeit ein sehr hoher Wert. Wenn ich raten
müsste max_int32 oder Zufallswerte.
Das klingt aber alles danach, als würde deine EEPROM-Ladedatei falsch
erzeugt. AVRDUDE bestätigt dir ja, dass sie korrekt geladen und zurück
gelesen worden ist.
CMake ist nun auch nicht unbedingt das, was jeder so aus dem Effeff
beherrscht. Vielleicht stellst du ja mal ein komplettes (Mini-)Projekt
zusammen, damit man das mal vollständig nachvollziehen kann.
Jörg W. schrieb:> Das klingt aber alles danach, als würde deine EEPROM-Ladedatei falsch> erzeugt. AVRDUDE bestätigt dir ja, dass sie korrekt geladen und zurück> gelesen worden ist.
Wie gesagt kann ich diese "EEPROM-Ladedatei" auf einen USB-Stick packen,
auf den alten Windows-PC kopieren und dort mit dem gleichen Programmer
auf den gleichen Chip spielen und es funktioniert ;)
> CMake ist nun auch nicht unbedingt das, was jeder so aus dem Effeff> beherrscht. Vielleicht stellst du ja mal ein komplettes (Mini-)Projekt> zusammen, damit man das mal vollständig nachvollziehen kann.
Vielleicht sollte ich mir einen der 30 JTAG-ICE-Dongle mal zu Gemüte
ziehen und dann Step-By-Step schauen, was dort im eeprom während der
Laufzeit liegt.
Grüße David
D a v i d K. schrieb:> Wie gesagt kann ich diese "EEPROM-Ladedatei" auf einen USB-Stick packen,> auf den alten Windows-PC kopieren und dort mit dem gleichen Programmer> auf den gleichen Chip spielen und es funktioniert ;)
Meine Glaskugel sagt:
Du hast die falsche Datei am Haken!
Das gezeigte avrdude Kommando ist eindeutig glücklich mit dem, was es
getan hat.
Von daher gibt es nur 2 Möglichkeiten:
1. avrdude lügt dich an
2. du verwechselst die *.eep Dateien
Ein paar -v zeigen dir deutlicher, was avrdude tut.
Einfach mal in den blauen Dunst :
Hast Du verschiedene .eep Dateien, die sich nur durch Groß- und
Kleinschreibeung des Dateinamens unterscheiden ? Das wäre so ein kleiner
aber manchmal gewaltiger Unterschied zwischen Windows und Linux.
angibst? Damit wird sicher gestellt, dass von evtl. mehreren Dateien
gleichen Namens die richtige genommen wird.
Wenn das nicht hilft, dann lies doch mal die EEPROM-Daten mittels
aus einem fehlgeflashten AVR aus (einmal von Windows und einmal von
Linux aus) und vergleiche die Daten untereinander und mit dem Original.
Schau dir die ausgelesene Datei auch manuell an: Stehen darin evtl. nur
0x00s oder 0xFFs?
D a v i d K. schrieb:> Vielleicht sollte ich mir einen der 30 JTAG-ICE-Dongle mal zu Gemüte> ziehen und dann Step-By-Step schauen, was dort im eeprom während der> Laufzeit liegt.
Falls du die Clones des uralten JTAGICE (manchmal auch als mkI
bezeichnet) meinst: da hast du mit dem ATmega88 keine Chance. Der
ATmega88 hat einfach mal kein JTAG.
Den EEPROM kannst du aber auch mit AVRDUDE problemlos rücklesen, nachdem
das Programm eine Weile gelaufen ist:
Führt zu einem Zustand auf dem Chip, der ähnlich/gleich aussieht, als
hätte ich die eep vergessen.
Dann flashe ich nur das *.eep unter Windows (siehe Bild: was ist das
eingentlich für eine Codierung und diese evtl Schlüssel des ganzen?)
Und ich erhalte die erwarteten Werte in den Variablen.
nun wiederhole ich nur:
Ist wieder alles "schlecht", was aber auch logisch klingt, wenn man die
folgenden Zeilen aus der Console ließt "avrdude: NOTE: "flash" memory
has been specified, an erase cycle will be performed"
Soweit so schlecht. Fallen euch noch parameter und/oder Randbedingungen
ein, die avrdude braucht, um gleichwertig mit dem WindowsTool das eep zu
flashen?
Grüße David
D a v i d K. schrieb:> Ist wieder alles "schlecht", was aber auch logisch klingt, wenn man die> folgenden Zeilen aus der Console ließt "avrdude: NOTE: "flash" memory> has been specified, an erase cycle will be performed"
Die EESAVE Fuse schon gefunden?
D a v i d K. schrieb:> Führt zu einem Zustand auf dem Chip, der ähnlich/gleich aussieht, als> hätte ich die eep vergessen.
Einzige Erklärung dafür: dein Programmer ist kaputt und funktioniert
trotz gegenteiliger Behauptung nicht korrekt. Aus irgendeinem Grund
funktioniert er unter Windows, möglicherweise benutzt dein myAVR Prog
Tool dort eine alte AVRDUDE-Version, die irgendwas anders macht, worauf
der Programmer anders reagiert – was auch immer. Wir werden es dir
leider nicht sagen können, denn „nach oben“ hin verhält er sich ja
korrekt. *)
Nimm dir einen ATmega8 oder ATmega168 oder sowas, bau dir ein USBasp
damit auf, nimm den komischen smartUSB-Dongle, um die USBasp-Firmware da
drauf zu dengeln, und danach legst du das Smartdingens in die Ecke.
*) Eine Vermutung hätte ich: sie haben möglicherweise nur das früher von
AVRDUDE benutzte SPIMULTI-Kommando für den EEPROM implementiert, aber
nicht die normalen Schreibkommandos. Seit Version 6.2 benutzt AVRDUDE
jedoch die (empfohlenen!) expliziten Kommandos.
Arduino Fanboy D. schrieb:> Vielleicht möchte ja nur die EESAVE Fuse gesetzt werden, damit die> Irrungen ein Ende haben?!
Was genau soll das mit der Unfähigkeit seines Programmers helfen, den
EEPROM initial überhaupt mal zu beschreiben?
fop schrieb:> Also vermutlich bekanntes Problem - aber unbekannte Lösung.
Naja, wenn der Hersteller des Tools das nicht reparieren will, dann
Lösung wie oben angedeutet: das Tool nur noch dazu benutzen, das
Henne-und-Ei-Problem für einen DIY-Programmer zu lösen.
Thread beobachten
Seitenaufteilung abschalten