Problem mit Self--Programming

OP #1190326
Hallo zusammen,

ich hab ein Problem mit Self-Programming bei ATmega644. Die Daten, die 
in den Flash programmiert werden sollen, werden mal geschrieben, mal 
nicht. Vielleicht kann mir jemand sagen, woran es liegt.

Der Codeteil zum Programmieren ist an floodloader angelehnt, benutzt die 
avr-libc und lautet:
1
unsigned int i;
2
unsigned int data;
3
unsigned char page_buffer[SPM_PAGESIZE];
4
unsigned int base_address; // Startadresse zu zu beschreibenden Page
5

6
// ... hier wird twi_input_buffer befüllt ...
7

8
// Schreiben der Daten in den Temporary Page Buffer
9
for( i = 0; i < SPM_PAGESIZE; i+=2)
10
{
11
  data = (page_buffer[i] << 8) | page_buffer[i];
12
  boot_page_fill_safe( base_address + i, data);
13
} 
14

15
// Löschen und Beschreiben der Page
16
boot_page_erase_safe( base_address);
17
boot_page_write_safe( base_address);
18
boot_spm_busy_wait();
19
boot_rww_enable_safe();
20

21
// Zur nächsten Page wechseln
22
base_address += SPM_PAGESIZE;

Seltsamerweise wird die Page immer gelöscht. Ich kann mit eine Page mit 
einem externen Programmer beschreiben und die Daten sind drin (Flash 
scheint also noch in Ordnung zu sein). Wenn ich die Page dann mit obigen 
Code neu beschreibe, ist sie mal korrekt beschrieben, mal nur mit 0xFF 
befüllt. Woran liegt das?
Sicher ist, dass das Array mit den korrekten Daten beschrieben ist.

Vielen Danke schon mal für eure Antworten,


Markus
OP
Hi Andreas,

danke noch mal für den Hinweis mit cli/sei. Leider war das aber nicht 
die Lösung.
Die Software erhält die Daten zum Programmieren über TWI. Leider hatte 
ich übersehen, dass beim Senden eines NOT ACK beim letzten Byte das 
Gerät vom Bus genommen wird und die STOP-Bedingung nicht mehr sieht. 
Erst beim STOP sollte das Programm in den Flash geschrieben werden.


Viele Grüße,

Markus
Markus Dörschmidt wrote:
> Die Software erhält die Daten zum Programmieren über TWI. Leider hatte
> ich übersehen, dass beim Senden eines NOT ACK beim letzten Byte das
> Gerät vom Bus genommen wird und die STOP-Bedingung nicht mehr sieht.

Der Slave sendet immer ACK, auch auf das letzte Byte.

Nur der Master muß NACK senden, damit er danach Stop senden kann.
Sonst legt der Slave das nächste Byte an. Wenn es 0xFF ist, Glück 
gehabt. Ist es aber 0x00, dann kommt das Stop nicht durch. Deshalb ist 
das NACK vom Master nötig.


Peter
OP
Laut Datenblatt der ATmegas sendet der Slave ein NOT ACK, wenn er keine 
weiteren Daten verarbeiten kann (siehe bspw. Datenblatt ATmega644, Seite 
218, 4. Absatz)

ACK / NOT ACK kann nur der Slave senden, der Master nur durch STOP / 
REPEATED START die aktuelle Übertragung beenden.
Markus Dörschmidt wrote:
> Laut Datenblatt der ATmegas sendet der Slave ein NOT ACK, wenn er keine
> weiteren Daten verarbeiten kann (siehe bspw. Datenblatt ATmega644, Seite
> 218, 4. Absatz)

Laut Datenblatt kann er zwar beides, man sollte aber besser ACK senden, 
um dem Master zu signalisieren, daß er alles empfangen hat.

Bei einem NACK weiß der Master nicht, ob er auch das letzte Byte 
empfangen hat (was blöd ist, da der Master nun nicht weiß, ob er ein 
Retry starten sollte).

Nur wenn der Master mehr Bytes zu senden versucht, als der Slave Puffer 
hat, kann man ein NACK senden, um dem Master anzuzeigen, daß ein Fehler 
aufgetreten ist.

Auch senden sämtliche I2C-ICs (IO-Ports, RTCs, EEPROMs) immer ein ACK, 
da sie ja nicht riechen können, welches das letzte Byte sein soll.

NACK vom Slave heißt im allgemeinen, Fehler oder der Slave ist busy 
(z.B. EEPROM schreiben).


> ACK / NOT ACK kann nur der Slave senden, der Master nur durch STOP /
> REPEATED START die aktuelle Übertragung beenden.

Nö.
NACK muß nur der Master-Receiver senden, damit danach das Stop/Start 
nicht in die binsen geht.
Das NACK vom Master bedeutet also ausnahmsweise mal nicht Fehler, 
sondern bereitet nur das Stop/Start vor.


Peter

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 17 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.