Forum: Compiler & IDEs Problem mit Self--Programming


von Markus D. (cipher1978)


Lesenswert?

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

von Andreas V. (tico)


Lesenswert?

Ich sehe nirgendwo ein cli() zum Abschalten der Interrupts. Wenn beim 
Schreiben was dazwischenfunkt, gehts daneben.

Gruss
Andreas

von Markus D. (cipher1978)


Lesenswert?

Hi Andreas,

stimmt, das sollte man tatsächlich verwenden. Steht ja auch so in der 
Doku.
Manchmal sieht man den Wald vor lauter Bäumen nicht...

Dank Dir!

von Markus D. (cipher1978)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von Markus D. (cipher1978)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.