www.mikrocontroller.net

Forum: Compiler & IDEs Problem mit Self--Programming


Autor: Markus Dörschmidt (cipher1978)
Datum:

Bewertung
0 lesenswert
nicht 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:
unsigned int i;
unsigned int data;
unsigned char page_buffer[SPM_PAGESIZE];
unsigned int base_address; // Startadresse zu zu beschreibenden Page

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

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

// Löschen und Beschreiben der Page
boot_page_erase_safe( base_address);
boot_page_write_safe( base_address);
boot_spm_busy_wait();
boot_rww_enable_safe();

// Zur nächsten Page wechseln
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

Autor: Andreas Vogt (tico)
Datum:

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

Gruss
Andreas

Autor: Markus Dörschmidt (cipher1978)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: Markus Dörschmidt (cipher1978)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Markus Dörschmidt (cipher1978)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.