Display Chip_ST7789V sporadische Abstürze wenn SPI>10MHz

[Dirk F. (dirkf)]

Hallo,
ich habe ein Display mit o.g. Chip per SPI an meine MCU PIC32MZ 
angeschlossen.
MISO  ist nicht angeschlossen, es kann also nur ins Display geschrieben 
werden.
Wenn ich das Datenblatt richtig verstanden habe, kann der Chip maximal 
15 MHz SPI Takt.
Größere Datenmengen werden per DMA-SPI zum Display geschaufelt.
Kleine Steuerbefehle via normal SPI.

Bei 10 MHz läuft alles sauber.
Wenn ich 20 MHz SPI Frequenz oder größer einstelle, kommt es sporadisch 
nach Sekunden/Minuten zum Reset der MCU.
Warum ist das so ?
Ich hätte erwartet, dass das Display eben nicht mehr funktioniert, aber 
warum schmiert die MCU ab ?
Es kommen ja keine Daten vom Display zurück, die falsch sein könnten.

[Dirk F. (dirkf)]

Auszug aus dem Datenblatt.

[Sebastian W. (wangnick)]

Dirk F. schrieb:
> Auszug aus dem Datenblatt.

Fehlende Abblockkondensatoren vielleicht? Gibt der PIC einen Grund für 
den Reset an?

LG, Sebastian

[Dirk F. (dirkf)]

Sebastian W. schrieb:
> Fehlende Abblockkondensatoren vielleicht?
Sind an der MCU vorhanden. 100nF || 10nF  pro Versorgungspaar.

> Gibt der PIC einen Grund für den Reset an?
Ja, WDT Reset.  Ist auf 2 Sekunden eingestellt.

[Harald K. (kirnbichler)]

Dirk F. schrieb:
> Ja, WDT Reset.  Ist auf 2 Sekunden eingestellt.

Nun, dann wird die Funktion, die Du verwendest, um den WD 
ruhigzustellen, wohl nicht mehr aufgerufen.

Ich denke, der Fehler liegt in der Schleif in Zeile 42.

[Peter D. (peda)]

Dirk F. schrieb:
> Ich hätte erwartet, dass das Display eben nicht mehr funktioniert, aber
> warum schmiert die MCU ab ?

Eine CPU schmiert nicht einfach so ab. Sie führt eine Exception oder ein 
Reset aus. Der Grund läßt sich dann in den entsprechenden Registern 
auslesen. Am einfachsten setzt man dazu entsprechende Breakpoints und 
läßt sich die Register im Debugger anzeigen.

[Dirk F. (dirkf)]

Peter D. schrieb:
> Eine CPU schmiert nicht einfach so ab. Sie führt eine Exception oder ein
> Reset aus. Der Grund läßt sich dann in den entsprechenden Registern
> auslesen. Am einfachsten setzt man dazu entsprechende Breakpoints und
> läßt sich die Register im Debugger anzeigen.

Er zeigt nach dem Reset 7 an:

//... perform application specific startup tasks
// next, check the cause of the Reset
debug[4] = 1;
    
if(RCON & 0x0003)
 {
// execute a Power-on Reset handler
   debug[4] = 2;
 }
 if(RCON & 0x0002)
 {
// execute a Brown-out Reset handler
    debug[4] = 3;
 }
if(RCON & 0x0080)
 {
// execute a Master Clear Reset handler
    debug[4] = 4;
 }
 if(RCON & 0x0040)
 {
 // execute a Software Reset handler
    debug[4] = 5;
 }
 if (RCON & 0x0200)
 {
// execute a Configuration Mismatch Reset handler
   debug[4] = 6;
 }
 if (RCON & 0x0010)
 {
// execute Watchdog Time-out Reset handler
    debug[4] = 7;
 }

[Peter D. (peda)]

Dirk F. schrieb:
> Ja, WDT Reset.  Ist auf 2 Sekunden eingestellt.

Na dann hängst Du in einer Schleife fest.

[Dirk F. (dirkf)]

Peter D. schrieb:
> Na dann hängst Du in einer Schleife fest.

Ja bestimmt.
Aber warum geht es bei 10 MHz ?

[Peter D. (peda)]

Dirk F. schrieb:
> Aber warum geht es bei 10 MHz ?

Irgendwas ist zu schnell fertig und Du machst irgendwas zu spät. Oftmals 
ist ein Fehler in der Reihenfolge von Zugriffen die Ursache.

Du kannst ein Timeout aufsetzen, das kürzer als der Watchdog ist und mit 
dem Watchdog rücksetzen. Im Timerinterupt gibst Du dann die Adresse auf 
dem Stack aus, d.h. die von ihm unterbrochen wurde.