AVRDUDE will Flash nicht lesen

[Christian Rötzer (Gast)]

Hallo Gemeinde,

ich bastel hier gerade einen Programmer für einen ATmega128 am
Parallelport zusammmen und möchte nun zum Testen einfach mal den
kompletten Flashspeicher auslesen. Ich starte AVRDUDE wie folgt:

avrdude -patmega128 -cmeiner -Uflash:r:read.bin:r

AVRDUDE läuft komplett durch. Er findet den Controller, liest ca. 30
Sekunden und sagt zum Schluß er schreibe nun read.bin. Leider ist die
Dateigröße 0 Byte :-(.
Das Lesen des EEPROMs funktioniert auf diese Weise, es entsteht eine
Datei mit der gewünschten Größe von 4096 Byte (wegen Raw-Format).

Was ist hier los?

Christian

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

> Leider ist die Dateigröße 0 Byte :-(.

Das wäre der erwartete Wert für einen leeren Flash-ROM. ;-)

Die 0xff am Ende der Datei werden ausgeblendet, da sie ja keinen
Informationswert haben.  Wenn dein Flash-ROM gar nicht programmiert
war, wird folglich alles ausgeblendet...

[Christian Rötzer (Gast)]

Hey!

Leeres Flash... nicht schlecht :)

Tja, das dürfte dann wohl die Ursache sein. Wollte halt erst lesen,
bevor ich mir dem Schreiben anfange. Der Baustein ist aber
lesegeschützt und somit dürfte das zum gleichen Ergebnis führen.

Danke Jörg und schönes Wochenende

Grüße

Christian

[mthomas (Gast)]

>Der Baustein ist aber lesegeschützt und somit dürfte das
>zum gleichen Ergebnis führen.

Eher nicht, wenn tatsaechlich via locks geschuetzt, wird zumindest beim
ATmega16 beim Auslesen eine Folge von Zahlen ausgegeben (0x00,0x01,0x02
etc.) also nicht 0xff.

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

Genau.  Es werden dann einfach die Bits von MOSI nach MISO
weitergereicht, sodass der SPI-Master sie um 8 Takte versetzt wieder
zurückgelesen hat.  Da das entsprechende Byte das niederwertige
Adressbyte ist, ergibt sich diese aufsteigende Reihenfolge (meiner
Erinnerung nach beim Flash als 00 00 01 01 02 02 infolge der
Wortadressierung, bei allen anderen Speicherbereichen unmittelbar
aufsteigend).

[Christian Rötzer (Gast)]

Ohne jetzt tiefer in das Thema einzusteigen, kann ich allerdings sagen,
daß nach einem Chip Erase und anschließendem Programmieren in der Tat
Daten zu lesen sind und auch in der Datei landen. Wie Jörg schon
erwähnte, läßt der AVRDUDE auch in diesem Fall die letzten FF's weg.
Diese Funktion ist meines Erachtens eher störend. Im schlimmsten Fall
bleibt ein abschließendes gewolltes FF auf der Strecke.

BTW:

Kann man den DUDE dazu überreden, daß wenn ich Daten ab z.B. 0x1E000
schreiben will (was mir nur über eine SREC-Datei gelingt), er
gefälligst die vorangehenden 0x1E000 Bytes (die eben nicht Teil meiner
SREC-Datei sind) NICHT explizit auf FF programmiert? Das kostet jede
Menge Zeit!

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

> Im schlimmsten Fall bleibt ein abschließendes gewolltes FF auf der
> Strecke.

Ja, und?  Ist doch nicht schlimm.  Da das ja das Bitmuster des
gelöschten ROMs ist, musst du das auch dann nicht programmieren,
wenn es gewollt ist.

> Kann man den DUDE dazu überreden, daß wenn ich Daten ab z.B. 0x1E000
> schreiben will (was mir nur über eine SREC-Datei gelingt), er

Korrektur: srec oder ihex können es.  Eine reine Binärdatei kann es
nicht, da sie keine Adressinformation enthält.

> gefälligst die vorangehenden 0x1E000 Bytes (die eben nicht Teil
> meiner SREC-Datei sind) NICHT explizit auf FF programmiert? Das
> kostet jede Menge Zeit!

Hat noch niemand implementiert.  Ja, könnte man machen.  Merke ich
auch, wenn ich mal einen Bootloader schreibe, aber da ich mittlerweile
praktisch keinen simplen Bit-banger mehr benutze (sondern entweder
STK500-Protokoll oder JTAG), stört's dort nicht so sehr.

[Christian Rötzer (Gast)]

> Korrektur: srec oder ihex können es.  Eine reine Binärdatei kann es
> nicht, da sie keine Adressinformation enthält.

Bei ihex habe ich die 1 von 0x1E000 in den Zeilen vermisst, woraus ich
schloss, dass ihex dann wohl nur 64k umfaßt. Wollte dann nicht weiter
Probleme suchen... ja, ist für einen Bootloader :)

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

> Bei ihex habe ich die 1 von 0x1E000 in den Zeilen vermisst, woraus
> ich schloss, dass ihex dann wohl nur 64k umfaßt.

Original ja, aber hier wird sogenanntes extended hex format benutzt,
das kommt damit zurecht.