ATxmega256A3 Problem mit avrdude (avrosp.exe funktioniert)

[Stephan S. (tozzi)]

Hallo zusammen,

ich bin noch recht unerfahren in dieser Thematik, verzeiht mir wenn ich 
hier gleich mit dem ersten Post mit einer Frage reinplatze.

Ich bin momentan dabei, einen Windows basierten Firmware Updater auf Mac 
OS X zu portieren.
Das Original verwendet AVROSP.exe zum Flashen, was auch problemlos 
funktioniert.

Da dieses Tool aber leider nie auf andere Systeme portiert wurde, möchte 
ich auf avrdude zurückgreifen, was ja an sich kein Problem sein 
sollte(?).

Ich versuche nun aber schon seit einigen Tagen erfolglos, die .hex Datei 
auf das Gerät zu flashen.

Das xml File für avrosp.exe enthält folgende Geräteparameter:

<PROG_FLASH>270336</PROG_FLASH>
<EEPROM>4096</EEPROM>
<PAGESIZE>512</PAGESIZE>
<SIGNATURE><ADDR000>$1E</ADDR000><ADDR001>$98</ADDR001><ADDR002>$42</ADDR002></SIGNATURE>

Aufgerufen so:

mode COM5 Data=8 Parity=n Baud=38400 DTR=OFF RTS=OFF
AVROSP -dATxmega256A3 -e -if"updatefile.hex" -pf

avdrude zeigt mit -v exakt dieselben Werte an.
Die Signatur stimmt auch überein.

./avrdude -p x256a3 -C ./avrdude.conf -c avr911 -P /dev/cu.usbserial-A504ZISZ -b 38400 -U flash:w:updatefile.hex -e -v

Connecting to programmer: .
Found programmer: Id = "AVRBOOT"; type = S
    Software Version = 1.7; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0xfa

avrdude: devcode selected: 0xfffffffa
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9842 (probably x256a3u)
avrdude: erasing chip
avrdude: reading input file "updatefile.hex"
avrdude: input file updatefile.hex auto detected as Intel Hex
avrdude: writing flash (142442 bytes):

Writing | ################################################## | 100% 57.92s

avrdude: 142442 bytes of flash written

Verify schlägt fehl beim ersten Byte (tut es aber auch mit avrosp.exe; 
Auslesen ist wohl nicht vorgesehen).

Nach dem Flashen startet nun das Gerät nicht mehr.

Erneutes Aufspielen mit avrosp.exe funktioniet, und anschließend startet 
das Gerät auch wieder ganz normal.

Ich bin momentan mit meinem Latein am Ende, 4 Tage Trial & Error.

Angeschlossen ist das Gerät über ein separates WiFi Modul (ohne dieses 
ist kein Firmware Update möglich); dies ist über USB angeschlossen 
(FT232R).

//Nachtrag:
Interessant ist auch, dass das erfolgreiche Flashen mit avrosp.exe fast 
6 Minuten dauert, avrdude aber nach 59 Sekunden damit durch ist.

Hat jemand eine Idee, was ich noch probieren kann?

[Stephan S. (tozzi)]

OK, ich habe den Fehler selbst gefunden, in avrdude's butterfly.c.

butterfly_set_extaddr wird nicht aufgerufen, somit wird ab 128K der 
Beginn des Speichers überschrieben (Statt "H" 0x010000 wird "A" 0x0000 
als Adresse geschickt).

Außerdem bestimmt avrdude die Buffergröße falsch (128 Byte statt 512).

Mit diesem (groben) Patch funktioniert es, ich werde das an die 
Entwickler weiterleiten, aber vorher noch dem buffersize Problem auf den 
Grund gehen.
Diese wird ja abgefragt und von avrosp.exe auch richtig verstanden.

--- butterfly.c.orig  2014-07-16 22:14:58.000000000 +0200
+++ butterfly.c  2017-05-23 22:49:20.000000000 +0200
@@ -321,6 +321,10 @@
   PDATA(pgm)->buffersize = (unsigned int)(unsigned char)c<<8;
   butterfly_recv(pgm, &c, 1);
   PDATA(pgm)->buffersize += (unsigned int)(unsigned char)c;
+
+  // overriding it for now
+  PDATA(pgm)->buffersize = 512;
+
   avrdude_message(MSG_INFO, "Programmer supports buffered memory access with buffersize=%i bytes.\n",
                   PDATA(pgm)->buffersize);

@@ -424,6 +428,7 @@

 static void butterfly_set_addr(PROGRAMMER * pgm, unsigned long addr)
 {
+if( addr < 0x10000 ) {
   char cmd[3];

   cmd[0] = 'A';
@@ -432,6 +437,19 @@

   butterfly_send(pgm, cmd, sizeof(cmd));
   butterfly_vfy_cmd_sent(pgm, "set addr");
+
+  } else {
+
+  char cmd[4];
+
+  cmd[0] = 'H';
+  cmd[1] = (addr >> 16) & 0xff;
+  cmd[2] = (addr >> 8) & 0xff;
+  cmd[3] = addr & 0xff;
+
+  butterfly_send(pgm, cmd, sizeof(cmd));
+  butterfly_vfy_cmd_sent(pgm, "set extaddr");
+  }
}

Leider werde ich avrdude aber aufgrund der GPL sowieso nicht verwenden 
können/dürfen...

//EDIT:
Würde den Faden gerne als "gelöst" markieren, das geht aber offenbar 
nicht.

[Rolf (Gast)]

Stephan S. schrieb:
> Leider werde ich avrdude aber aufgrund der GPL sowieso nicht verwenden
> können/dürfen...

Besser ist es.
Wenn man von Problemen mit der MC-Programmierung hört hat meistens 
dieses dämliche avrdude seine Hand im Spiel.

[Stephan S. (tozzi)]

Ja, ist schon erstaunlich, dass das avrosp.exe Tool von 2004 bereits die 
erweiterte Adressierung beherrscht, avrdude hingegen nicht...
Gut, Letzteres deckt halt auch einen viel größeren Bereich ab und ich 
will das gar nicht schlecht reden. Für die meisten funktioniert es ja.

Aber wenn ich schon "in die Matrix eintauche" und das Protokoll auf Bit 
und Byte Ebene durchgehen muss, kann ich auch gleich meine eigene, 
"monolithische" Lösung durchziehen und das vernünftig in den Installer 
einbauen, grafischer Fortschrittsbalken und Lokalisierung inklusive...

Wenn ich da jetzt noch den Source Code, meinen Patch und einen 
No-Warranty Disclaimer dazupacke, wird mein Auftraggeber nicht 
sonderlich begeistert sein.
Soviel zum Thema GPL...

Immerhin kann ich jetzt als Nebenprodukt eine Source Code basierte Linux 
Version für die Kommandozeile obendrein geben, halt dann mit den ganzen 
GPL Spezialitäten im README.

Die low-level Lösung hätte ich mal gleich angehen sollen, anstatt 5 Tage 
mit Trial/Error zuzubringen. Wollte es einfach nicht glauben...