Programm startet neu bei Zugriff auf array

[riz (Gast)]

Hallo Zusammen

Folgendes Problem bekomme ich nicht gelöst:

Ich schreibe per soft SPI Daten an ein Display (DOGXL160x104 pxl, zu 26 
pages, pro pixel 2 bit für Graustufen) und parallel dazu lege ich die 
Daten in einem Array (lcd_buffer[][]) ab um später pixelweise logische 
Verknüpfungen damit machen zu können (Display ist in SPI-mode write 
only).

Problembeschreibung:
Nach Aufruf der Produre lcd_clrscr() in lcd.c aus dem Hauptprogramm raus 
geht alles gut, aber nachdem durch die for-Schleifen alle array Zellen 
beschrieben sind, fängt das Programm neu an und bleibt in einer 
Endlosschleife hängen. Manchmal läuft es auch nur bis zur ominösen 
150-ten Spalte.

void lcd_clrscr(uint8_t fill)
{
  uint8_t i,j;
  
  
  for (i=0;i<(XPIXEL-9);i++){
    printf("i %d",i);
    lcd_send_command(i&0x0F);      //LSB adress
    lcd_send_command(0x10+(i>>4));//MSB adress
    
    //set page adress of first half of byte
    lcd_send_command(0x60);

    for (j=0;j<((YPIXEL/4));j++)
    {lcd_send_data(fill);
    lcd_buffer[i][j]=fill;
    //printf("j %d\n",j);
    };
  };
    
}

Das für mich unverständliche ist, dass alles normal läuft, wenn ich die 
Zeile mit der Zuweisung in das array

lcd_buffer[i][j]=fill;

rauslasse.
lcd_buffer[][] wird in lcd.c definiert. Die Sourcen für das Gesamte 
Testprojekt im Anhang.

uC: ATMega1284P
Compiler: avr-gcc

[J.-u. G. (juwe)]

riz schrieb:
> lcd_send_data(fill);

Ich habe Deine Sourcen kurz überflogen und nirgendwo eine Definition von 
"lcd_send_data" gefunden, sondern lediglich folgende Textersetzung in 
lcd.h:

#define lcd_send_data(data) lcd_send(data, 1)

Diese greift hier natürlich nicht. Ich kann mir nicht vorstellen, dass 
sich Dein Projekt ohne Fehler- bzw. Warnmeldungen kompilieren lässt.

[riz (Gast)]

Hallo J.u.G.

gehen tut es, warum auch immer. Keine Fehler und das Display tut das was 
es soll (wenn ich wie oben beschriebe bei kleinen Spaltenzahlen bleibe). 
Hab diese Routine aus dem Forum.
Nichts destotrotz werd' ich das mal ersetzen.

Hab inzwischen neue Info. Wenn ich mehr Funktionalität reinbaue (hab 
gerade mal meine TWI-Bibliotheken mit eingebunden), dann geht schon ab 
Spalte 50 nix mehr...
Ich vermute es ist irgendein Speicherproblem, aber welches...

[riz (Gast)]

wie befürchtet : Ersetzen von

#define lcd_send_data(data) lcd_send(data, 1)

durch

void lcd_send_data (uint8_t data)
{
  lcd_send(data,1);
}

und die entsprechende Definition im header file bringt nix...

[Bronco (Gast)]

Watchdog?
Überlauf von lcd_buffer[][]?

[Oliver (Gast)]

riz schrieb:
> Das für mich unverständliche ist, dass alles normal läuft, wenn ich die
> Zeile mit der Zuweisung in das arraylcd_buffer[i][j]=fill;
> rauslasse.

lcd_buffer ist schlappe 4196 Byte groß. Du solltest vielleicht doch mal 
im Datenblatt nachschauen, wie groß das SRAM des ATMega168 ist.

Oliver

[riz (Gast)]

@Oliver
mir ist schon klar wie groß das array lcd_byte ist, deshalb habe ich ja 
auch einen Mega128 genommen. Steht in meinem ersten Beitrag ganz unten. 
Kann sein, dass in den Kommentaren in der Source noch irgendwo Mega16 
steht, ist aber definitiv ein Mega128, sorry für die Verwirrung.

@Bronco
Watchdog ist nicht an (Fusebit 4 unprogrammed) und die Bits in WDTCSR 
sind alle 0 per default.
Was genau meinst du mit Überlauf? Die Indices i und j in 
lcd_buffer[i][j] laufen nie über den definierten Bereich raus, das habe 
ich mittels UART geprüft, siehe das Codeschnipsel im ersten Beitrag.

Gibt's sonst noch Ideen?

danke
riz

[Thomas M. (thomil)]

riz schrieb:
> mir ist schon klar wie groß das array lcd_byte ist, deshalb habe ich ja
> auch einen Mega128 genommen.

Der Mega128 hat aber auch nur 4KB RAM. Dein lcd_buffer[][] ist größer. 
Dabei ist der Verbrauch für die anderen Sachen und Stack noch nichtmal 
eingerechnet.

Edit: Ich sehe gerade im OP steht "ATMega1284P". Bei dem sollte sich das 
ausgehen...

[Bronco (Gast)]

riz schrieb:
> Gibt's sonst noch Ideen?

Mach mal lcd_buffer deutlich größer und initialisier alle mit einem 
Codewort, z.B. 0xCAFEAFFE.
Bau einen kleine Checkroutine ein, die prüft, ob in dem Bereich jenseits 
der normalen Größe von lcd_buffer dieser Code überschrieben wurde.

[riz (Gast)]

Ahhh, da kommen wir der Sache schon näher.
Hab mir per Excel eine Array-Belegung gestrickt, die aufsteigende Zahlen 
in der Spalte und Zeile hat. (siehe Definition lcd_buffer im Anhang). 
Dann per UART jedes Element anzeigen lassen

for (i=0;i<YPIXEL/4+1;i++){
  for (j=0;j<XPIXEL+15;j++){
    printf("i %d",i);
    printf("j %d",j);
    printf("b %d\n",lcd_buffer[j][i]);
  }
}

und siehe da, es gibt bei j=146 ein Problem für jedes i. Ausschnitt aus 
dem Terminal :
(bis da ist alles o.k.)
i 0j 145b 146  (das passt noch, soll 146 sein)
i 0j 146b 99   (das ist Müll, soll 147 sein)
i 0j 147b 0    (das ist Müll, soll 148 sein)
i 0j 148b 16   (das ist Müll, soll 149 sein)
i 0j 149b 150  (das passt wieder, soll 150 sein)
(ab da ist wieder alles o.k.)

D.h. immer die Indices j=146 bis 148 verlieren ihren Wert, egal für 
welches i.
Und jetzt???

[troll (Gast)]

riz schrieb:
> Und jetzt???
Die Arraybelegung so lassen und an verschiedenen Stellen im Programm 
mittels if überprüfen und bei Fehler eine Meldung ausgeben. Vielleicht 
kann man die Sache so eingrenzen. Alternativ das ganze Programm mal für 
PC umschreiben und durch einen guten Debugger jagen (der von MS soll ja 
ganz gut für solche Speichergeschichten sein?) und gucken ob das 
Programm irgendwo Mist baut.

[riz (Gast)]

hallo troll

hab das mal umgesetzt mit dem Anzeigen an versch. Positionen. Leider 
hilft's nicht weiter, weil sofort nach der Init-Routine des UART der 
Fehler schon da ist und das ist die 2. Zeile im Hauptprogramm :-((
Ich hab mich dazu entschlossen das Problem zu umschiffen indem ich den 
lcd_buffer gar nicht mehr benutze (und auch nicht definiere) und halt 
alles im Display überschreibe. Ist nicht schön, aber für meine Zwecke 
geht's gerade. Resignation pur...

danke an alle die bisher mitgeholfen haben.

[troll (Gast)]

Schuss ins Blaue: Könnte es sein dass der verwendete µC einfach nicht 
genug RAM hat? Eventuell den Code mal für PC umschreiben und gucken ob 
da alles läuft?

[Bronco (Gast)]

riz schrieb:
> weil sofort nach der Init-Routine des UART der
> Fehler schon da ist

ISt doch schon mal was.

Prüf es doch davor und setze eine LED je nach Zustand.

In Deiner RS232.c fällt mir im Init folgendes auf:

stdout = &uart_str;

Vielleicht hast Du hier einen amoklaufenden Zeiger?

[Klaus D. (kolisson)]

.. und bei ominösen Neustarts etc. auch immer ein Auge auf den Stack 
werfen.

Gruss K.

[troll (Gast)]

Klaus De lisson schrieb:
> .. und bei ominösen Neustarts etc. auch immer ein Auge auf den Stack
> werfen.

Jup, daher meine Frage nach dem RAM.