avrdude und eeprom

[Christian H. (netzwanze)]

Ich habe hier einen merkwürdigen Effekt, den ich mir nicht erklären 
kann.
Bisher habe ich das EEPROM der AVRs nur vom Prozessor aus benutzt. Nun 
wollte ich das erste Mal die EEPROM-Daten beim Programmieren vorgeben 
(Lookup-Table).


Zunächst einmal die Eckdaten:
avrdude 5.8 (linux 64bit) [Fedora 12]
ATtiny85 in Standardschaltung (Reset = 10kOhm-Pullup; 100nF an Vcc)
Verwendete Programmer: ISP-PROG; AVR500-Nachbau ("Der Hammer"); Dragon
Alle ISP-Mode

Quelldaten: Binärfile mit 256 16-Bit-Worten 0x0001 bis 0x00ff (also 
Dateilänge 512Bytes)

Ich schreibe diese Daten mittels (ISP-PROG):
avrdude -pt85 -cstk500v2 -P/dev/ttyACM0 -Ueeprom:w:datei.eep:r

Avrdude liefert mir für die ersten 25% OK; dann Fehler und für die 
letzen 25% wieder OK.

Ich habe bereits mehrere ATtiny85 durch. Überall das selbe.

Zur Kontrolle habe ich das EEPROM direkt vom Tiny schreiben lassen:

uint16_t lookup[256] EEMEM;

int main(void) {
  unsigned char i;
  for(i = 0; i < 256; i++) {
    eeprom_write_word(&lookup[i],i);
  }
}

und mit avrdude ausgelesen. Der Inhalt stimmt mit den erwarteten 
überein.
Schreibe ich die selben Daten nochmal mit dem Programmer, gibt es wieder 
die Fehler.

Programmieren des Flash sowie der Fuses funktioniert einwandfrei.
Ich sehe es daran, dass mein eigentliches Programm (das tut hier aber 
nichts zur Sache) genau das tut, was es soll (modifizierten DS18B20 
simulieren).

Am Programmer kann es nicht liegen, da ich mehrere probiert habe.
Das EEProm ist auch in Ordnung, sonst könnte ich es ja nicht vom Tiny 
aus beschreiben.

Ich habe daher den avrdude in Verdacht.

Fragen:
Hat avrdude eine Macke (welche Versionen)?
Ist dies ein bekanntes Problem?
Oder mache ich hier irgend etwas falsch?

[Christian H. (netzwanze)]

Noch eine Ergänzung:

Adresse 0x180 bis 0x1ff stimmen mit den programmierten Daten überein.
Adresse 0x000 bis 0x07f bekommt die Daten, die für 0x080 bis 0x0ff 
gedacht sind.
Adresse 0x080 bis 0x17f werden nicht programmiert. In diesem Bereich 
werden auch die Fehler gemeldet.

Mir scheint, dass da etwas mit der Adressierung nicht stimmt.
Ich werde mir heute abend aber mal ein Windows-Notebook aus der Firma 
ausleihen und damit testen.

[Bernhard M. (boregard)]

Hi,

kannst Du die ISP clock speed heruntersetzen? Also die '-B' option bei 
avrdude?
Ich habe die Erfahrung (mit USBasp) gemacht, daß man mit der 
Flash-Programmiergeschwindigkeit höher gehen kann, als mit EEprom (der 
Grund ist mir aber nicht richtig klar).

Gruß,
Bernhard

[Jörg W. (dl8dtl) (Moderator)]

Christian H. schrieb:

> Hat avrdude eine Macke (welche Versionen)?

Keine Ahnung, sollte zumindest nicht passieren.  Du kannst ja mal
für alle Fälle einen Bugreport aufmachen:

https://savannah.nongnu.org/bugs/?group=avrdude

Dort bitte die genauen Angaben zum Programmiergerät, benutzten
Kommando usw. hinterlegen, außerdem noch die EEPROM-Datei (wenn
möglich, ansonsten einen Fake) und die Ausgabe vom avrdude mit
den zusätzlichen Optionen -vvvv als Anhang dran hängen.

[Christian H. (netzwanze)]

So, ich habe mal einige ältere Versionen ausprobiert. Bei Version 5.7 
wie auch 5.8 treten die Probleme aus. Version 5.6 funktioniert, 
zumindest mit dem eeprom auf dem attiny85, ohne Probleme. Also wirklich 
ein Bug.

Ich habe mal einen Bugreport eingeschickt und werde erstmal mit Version 
5.6 arbeiten.

[Christian H. (netzwanze)]

Hatte erst die -vvvv Ausgabe vergessen und dann war sie noch zu lang und 
wurde nicht übernommen. Jetzt sollten alle notwendigen Files im 
Bugreport verfügbar sein.

[Christian H. (netzwanze)]

Bernhard M. schrieb:
> kannst Du die ISP clock speed heruntersetzen? Also die '-B' option bei
> avrdude?
Egal, was ich bei -B eintrage; keine Verbesserung.

[Jörg W. (dl8dtl) (Moderator)]

Kannst du eine Version direkt aus dem SVN probieren?  Ich kann
deine Probleme jedenfalls damit nicht (mehr?) nachvollziehen,
zumindest nicht mit einem Original STK500.

[Christian H. (netzwanze)]

Werde ich heute abend probieren.
Ich werde auch noch mehrere Tests machen und alles dokumentieren.

Danke

[Christian H. (netzwanze)]

Die aktuelle CVS-Version funktioniert mit allen von mir getesteten 
EEPROM-Files.

Die Debug-Ausgabe gibt bei der Version 5.8 (nicht selber compiliert, 
sondern aktuell bei Fedora 12 dabei) unter anderem Folgendes aus:

avrdude-5.8: Send: . [1b] . [05] . [00] . [02] . [0e] . [03] . [94] . 
[85]
avrdude-5.8: Recv: . [1b]
avrdude-5.8: Recv: . [05]
avrdude-5.8: Recv: . [00]
avrdude-5.8: Recv: . [03]
avrdude-5.8: Recv: . [0e]
avrdude-5.8: Recv: . [03]
avrdude-5.8: Recv: . [00]
avrdude-5.8: Recv: . [00]
avrdude-5.8: Recv: . [10]
            Vtarget         : 0.0 V
            SCK period      : 0.1 us

Die 0.1 us sind sicherlich zu wenig.

Mit -B10 gibt es keine Verbesserung, nur die Ausgabe der Fehler wird 
langsamer.

Version 5.6 meldet "SCK period : 127 us"  und es klappt mit dem 
Programmieren.

Version 5.8cvs meldet "SCK period : 20.7 us" und es klappt ebenfalls.

Das erstmal mit dem ISP-Prog (günstiger Programmer bei Ebay; ist statt 
in einem Gehäuse in Plexiglasplatten "eingebaut").


Zweiter Programmer "HVprog" von Tobias Hammer, gleiche Probleme:

avrdude-5.8 funktioniert nicht: SCK period : 9,8 us
avrdude-5.8csv funktioniert(!): SCK period : 9,8 us
avrdude-5.6    funktioniert(!): SCK period : 9,8 us

Genauso mit dem Dragon (habe dummerweise mein 6pin->10pin Adapterkabel 
zerstört, so dass ich weder Zeitangaben noch Debugausgabe vorliegen 
habe)

Das es an meinem Programmer liegen soll, kann ich mir nicht vorstellen, 
da ich verschiedene probiert habe.

Interessanterweise passiert noch folgendes:

Klappt es mit der 5.8er Version nicht und ich schreibe die Datei dann 
mit der 5.6er ins EEPROM (funktioniert), klappt es anschließend auch mit 
der 5.8er.

Nehme ich dann ein Testfile mit lauter Nullen und schreibe wieder mit 
der 5.8er, gibt es wieder Fehler.

Die Fehler werden also nur gemeldet, wenn neue Daten geschrieben werden. 
Erfolgt ein Überprogrammieren mit den gleichen Daten wie bereits 
vorhanden, gibt es keine Fehler.

Der Testaufbau ist immer gleich. Ich verwende auch die selben Kabel; bis 
auf den Dragon, da hatte ich ein anderes Kabel 6pin -> 10pin).


Naja, da es mit der CVS-Version klappt, werde ich die nun verwenden und 
nicht noch mehr Zeit mit der Fehlersuche verbringen. Ich muss endlich 
mit meinem AVR-Programm weiter kommen.

Die Debugausgaben sowie die Testfiles hänge ich mal an - falls sie 
jemanden interessieren.

[Jörg W. (dl8dtl) (Moderator)]

Christian H. schrieb:

> Naja, da es mit der CVS-Version klappt, werde ich die nun verwenden und
> nicht noch mehr Zeit mit der Fehlersuche verbringen. Ich muss endlich
> mit meinem AVR-Programm weiter kommen.

Nun, die Bugs vergangener Releases kann ich ohnehin nicht mehr
reparieren. ;-)  Schön, wenn es jetzt geht, dann kann ich den
Bugreport schließen.

Es wird übrigens dann bald eine 5.9 geben.