C + TFT +SD ==> Unlogischer Fehler. Mit Wissenschaftlichen Mitteln nicht erklärbar!

[M. Н. (Gast)]

Hallo Leute,

ich habe ein Display mit SSD1963 Controller an einem PIC32MX340F512H.

ICh versuche ein Bild von SD-Karte (Roh-Format) an das Display zu 
senden.

Der Code:

for(i=0;i<(800*480);i++)
{
  f_read(&file1, buffer, 2, &read);
  LCD_WR_Data((((short)buffer[1])<<8)+buffer[0]);
}

Die Funktion f_read liest die daten korrekt ein... (bereits überprüft).
Leider Stürtzt der µC nach etwa der Hälfte des Bildes ab und bricht die 
for Schleife ab.. und setzt alle Pins auf 0.
Mit folgendem Code passiert das nicht:

for(i=0;i<(800*480);i++)
{
  f_read(&file1, buffer, 2, &read);
        buffer[0] = 0xFF;
        buffer[1] = 0x1C;
  LCD_WR_Data((((short)buffer[1])<<8)+buffer[0]);
}

Die Daten werden bei diesem Code ausgelesen und durch Konstanten 
überschrieben. Dann stürtzt der Controller nicht ab und füllt das ganze 
Bild mit 0x1CFF-Pixeln (RGB565 16-bit Color).

Ich finde es sehr komisch, dass der Controller Schei*e baut, wenn die 
Daten im ursprünglichen Zustand bleiben.


Kann mir jemand helfen..

Gruß M.H.

Ps Ich weiß, dass der Fehler technisch eigentlich gar nicht möglich sein 
dürfte.. meine einzige Hoffnung ist, dass der C32 Compiler da was kaputt 
compiliert bzw. optimiert.


Bitte helft mir...

[Floh (Gast)]

Buffer ist wie definiert? Möglicherweise zu groß für deinen RAM?

[M. Н. (Gast)]

Floh schrieb:
> Buffer ist wie definiert? Möglicherweise zu groß für deinen RAM?

char buffer[32];


Ram : 1756 Bytes von 32768 Bytes... Also noch mehr als genug verfügbar

[Martin M. (capiman)]

Kommentiere mal die Zeile

LCD_WR_Data((((short)buffer[1])<<8)+buffer[0]);

aus und teste, ob die Schleife dann komplett durchläuft.

Was macht LCD_WR_Data?

[M. Н. (Gast)]

Disassembly sieht so aus:

223:                   f_read(&file1, buffer, 2, &read);
9D00A800  27C30090   addiu       v1,s8,144
9D00A804  27C200B0   addiu       v0,s8,176
9D00A808  3C04A000   lui         a0,0xa000
9D00A80C  248404B4   addiu       a0,a0,1204
9D00A810  00602821   addu        a1,v1,zero
9D00A814  24060002   addiu       a2,zero,2
9D00A818  00403821   addu        a3,v0,zero
9D00A81C  0F400DE8   jal         0x9d0037a0
9D00A820  00000000   nop         
224:                   LCD_WR_Data((((short)buffer[1])<<8)+buffer[0]);
9D00A824  83C20091   lb          v0,145(s8)
9D00A828  3042FFFF   andi        v0,v0,0xffff
9D00A82C  00021200   sll         v0,v0,0x8
9D00A830  3043FFFF   andi        v1,v0,0xffff
9D00A834  83C20090   lb          v0,144(s8)
9D00A838  3042FFFF   andi        v0,v0,0xffff
9D00A83C  00621021   addu        v0,v1,v0
9D00A840  3042FFFF   andi        v0,v0,0xffff
9D00A844  7C021620   seh         v0,v0
9D00A848  00402021   addu        a0,v0,zero
9D00A84C  0F402C85   jal         0x9d00b214
9D00A850  00000000   nop

[M. Н. (Gast)]

Martin Maurer schrieb:
> Kommentiere mal die Zeile
>
> LCD_WR_Data((((short)buffer[1])<<8)+buffer[0]);
>
> aus und teste, ob die Schleife dann komplett durchläuft.

Ja die Schleife läuft dann komplett durch.

Martin Maurer schrieb:
> as macht LCD_WR_Data?

void LCD_WR_Data(short dat)
{
  PORTESET = (1<<5) | (1<<1);
  PORTB = dat;
  PORTECLR = (1<<3);

        /*Hier sind in echt ein paar asm("nop"); Befehle dazwischen. Hab    die jetzt halt eingespart, damit man das besser lesen kann*/

  PORTESET = (1<<3);
  
}

[M. Н. (Gast)]

ich hatte auch das Problem, dass er bei:

#define LCD_RS PORTDbits.RD1


LCD_RS = 0;

den ganzen PortD auf 0 gesetzt hat.

Wenn ich dann geschrieben habe

PORTDbits.RD1 = 0;

dann ist nur das Bit 1 auf 0 gegangen...

Also auch so ein komischer Compiler-Schrott.

[M. Н. (Gast)]

Ich geh jetzt bloß ins Bett...


Hab seit gestern 20 Uhr dran gesessen. Sollte mal schlafen...

[Johannes E. (cpt_nemo)]

M. H. schrieb:
> Leider Stürtzt der µC nach etwa der Hälfte des Bildes ab und bricht die
> for Schleife ab.. und setzt alle Pins auf 0.

Was genau meinst du mit "bricht die for Schleife ab"? Macht der 
Controller einen Reset oder geht die Ausführung nach der for-Schleife 
weiter?

Hast du statt:

buffer[0] = 0xFF;
buffer[1] = 0x1C;

auch mal andere Werte ausprobiert (z.B. zwei mal 0x00 oder zwei mal 
0xFF)? Wenn einer dieser beiden Werte auch zum Absturz führt, dann liegt 
es vielleicht an einer einzelnen Leitung, die einen Kurzschluss zu GND 
oder VCC hat.

M. H. schrieb:
> Ich finde es sehr komisch, dass der Controller Schei*e baut, wenn die
> Daten im ursprünglichen Zustand bleiben.

Ich würde erst mal nicht davon ausgehen, dass der Compiler daran schuld 
ist; vermutlich eher ein Hardware-Problem. Kannst du den Code auch im 
Simulator ausführen?

[Frank K. (fchk)]

Welchen Compiler nimmst Du?

Meine Empfehlung: C32 Version 1.12 (die letzte 1'er) und MPLAB8. Genau 
diese Kombination!

Probiere es damit mal.

fchk

[M. Н. (Gast)]

Frank K. schrieb:
> Welchen Compiler nimmst Du?
Ich weiß nicht genau, aber in MPLAB, ich benutze übrigens 8.85, zeigt er 
mir bei Language Toolsuite immer v2.02 bei allen Exe-Dateien des 
Compilers.
Also denke ich dass ich compiler v2.02 habe.

[M. Н. (Gast)]

Frank K. schrieb:
> Meine Empfehlung: C32 Version 1.12 (die letzte 1'er)

Wo bekomme ich die her? Bei Microchip gibt's nur die Neueste: v2.02a.

[M. Н. (Gast)]

Johannes E. schrieb:
> Hast du statt:
> buffer[0] = 0xFF;
> buffer[1] = 0x1C;
>
> auch mal andere Werte ausprobiert (z.B. zwei mal 0x00 oder zwei mal
> 0xFF)?

Ja habe ich. Das funktioniert mit jedem Wert.

Johannes E. schrieb:
> Was genau meinst du mit "bricht die for Schleife ab"? Macht der
> Controller einen Reset oder geht die Ausführung nach der for-Schleife
> weiter?

Ja, er macht einfach nach der for-Schleife weiter und beginnt mit einem 
VS1053b eine MP3-Datei wiederzugeben. Das funktioniert super.

Edit:

Interessant ist auch:
Wenn ich schreibe

for(i=0;i<(800*480);i++)
{
  LCD_WR_Data(i);
}

Dann zeigt er auf'm Display das Muster an, das dadurch entsteht. 
Funktioniert.

Wenn ich aber schreibe:

for(i=0;i<(800*480);i++)
{
  LCD_WR_Data(~i);
}

gehen sofort alle Pins des µC auf 0. und dann wieder in den 
ursprünglichen zustand. (Dauert keine Millisekunde). Dannach macht der 
Controller dann einfach weiter (nach der for schleife mit dem Rest des 
Programms). Dadurch wird dann das Display geresettet.

[Martin M. (capiman)]

Wie hast Du eigentlich i angelegt?
Hast Du (als Workaround) schon mal versucht
statt for-next ein while zu benutzen?
Oder 2 kleinere Schleifen?

Hast Du mal geschaut, ob irgendwo beschrieben ist,
was in der v2.02a verändert wurde?
Vielleicht mal updaten auf die v2.02a?

Falls das Projekt übertragbar wäre:
Könntest Du das gesamte Projekt mal hochladen?
Vielleicht könnte Frank es zum Test mit seiner Version übersetzen?

[M. Н. (Gast)]

Martin Maurer schrieb:
> Wie hast Du eigentlich i angelegt?

int i;

Ich werde mal schauen, was bei der neuen Version anders ist.

[M. Н. (Gast)]

Ich hab jetzt mal die Installer exe von C32 im Downloads Ordner 
wiedergefunden. Es ist die v2.02a.


Hab jetzt mal das Projekt angehängt. Ist aber ziemlich verwirrend, da es 
nur zum testen gadacht war. Sieht halt 'n bisschen durcheinander aus...

[Arc N. (arc)]

Wie wird denn gedebuggt?
Auf dem Port B liegen normalerweise auch PGEC1, PGED1...
DEVCFG0 passend gesetzt?

[Der (Gast)]

Tipp:

Schreibe mal bei den benötigten Variablen das Vorzeichen hin. Am Besten 
unsigned.

Dann kannst du folgenden Code verwenden und mit SingeStep debuggen, am 
besten im Dissasembly (Optimierung ausschalten). So siehst du genau, an 
welcher Stelle er aussteigt.

...
unsigned short BufferTemp;
...

for(i=0;i<(800*480);i++)
{
   f_read(&file1, buffer, 2, &read);
   buffer[0] = 0xFF;
   buffer[1] = 0x1C;
   BufferTemp = (unsigned short)(buffer[1])<<8);
   BufferTemp = BufferTemp + (unsigned short)buffer[0];
   LCD_WR_Data(BufferTemp);
}

[M. Н. (Gast)]

Geht. Wenn ich aber das

buffer[0] = 0xFF;
buffer[1] = 0x1C;

weglasse

verreckt alles wieder

[Frank K. (fchk)]

M. H. schrieb:
> Frank K. schrieb:
>> Meine Empfehlung: C32 Version 1.12 (die letzte 1'er)
>
> Wo bekomme ich die her? Bei Microchip gibt's nur die Neueste: v2.02a.

Das ist die Archiv-Seite. Da gibts jede alte Version.

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023073

fchk

[Der (Gast)]

Steht denn in BufferTemp der richtige Wert?

Wo gibt es Doku zu f_read? Riecht ein bisschen nach Stack Overflow.

Gruß

[Der (Gast)]

Nachtrag:

In der Variable read steht, wie viele Bytes tatsächlich gelesen wurden. 
Ist read groß genug?
Überprüfe auch nach jedem f_read, ob tatsächlich genügend Bytes gelesen 
wurden.

[M. Н. (Gast)]

wenn ich die gelesenen Bytes über f_write(&file2 ....

in eine zweite Datei schreibe, dann hat er die Datei 1 zu 1 kopiert. 
Habs nachgeprüft. Die Daten werden 100% korrekt ausgelesen.

M. H. schrieb:
> Interessant ist auch:
> Wenn ich schreibefor(i=0;i<(800*480);i++)
> {
>   LCD_WR_Data(i);
> }
> Dann zeigt er auf'm Display das Muster an, das dadurch entsteht.
> Funktioniert.
>
> Wenn ich aber schreibe:for(i=0;i<(800*480);i++)
> {
>   LCD_WR_Data(~i);
> }
> gehen sofort alle Pins des µC auf 0. und dann wieder in den
> ursprünglichen zustand. (Dauert keine Millisekunde). Dannach macht der
> Controller dann einfach weiter

Hier hat das gar nichts mit SD-Karte zu tun. Es funktioniert nicht nur 
weil ich ~i statt i verwende.

Ich verzweifle an dem Problem. Vor Allem, dass das so unlogisch ist 
raubt einem den letzten Nerv

[Karlheinz (Gast)]

Hallo,

> for(i=0;i<(800*480);i++)

wie ist denn dein "i" definiert ???, hoffentlich ein "long" denn sonst 
wird er nie fertig, weil
800*480 = 38400 (0x5dc00)

[Karlheinz (Gast)]

Hallo nochmal
Korrektur, da eine Null vergessen in 384000

> for(i=0;i<(800*480);i++)

 wie ist denn dein "i" definiert ???, hoffentlich ein "long" denn sonst
 wird er nie fertig, weil
 800*480 = 384000 (0x5dc00)

[Glaskugel (Gast)]

Geht es mit :

buffer[0] = 0x00;
buffer[1] = 0x00;

Wenn nicht, sollte klar sein woran es liegt

[Marco L. (lehmi)]

Hast du mal die Datenleitungen auf Kurzschlüsse untereinander und zu 
Masse / Versorgung geprüft? Irgendein Bitmuster scheint den Controller 
zu resetten oder die Spannungen zusammenbrechen zu lassen.

Grüße

[M. Н. (Gast)]

Ich habe etwas festgestellt.

Wenn ich schreibe PORTE |= (1<<4); ,

dann werden sporadisch andere Bits des Ports auf null gesetzt. Das 
dürfte doch eigentlich nicht passieren, oder?

Werde die Hardware nochmal checken.

Martin Maurer (capiman) hat mir freundlicherweise 2 Hex-Files mit seinen 
Versionen compiliert.
Das Problem besteht aber weiterhin...

[Marvin M. (Gast)]

Hallo,

hast du noch irgendeine Interrupt-Routine am Laufen? Evtl. zerhackts dir 
da irgendwelche nicht-atomaren Zugriffe?

[M. Н. (Gast)]

Es läuft nur ein Coretimer Interrupt.Der zählt ein paar Variablen hoch 
und generiert jede Millisekunde die Zeit für Das FAT-Modul. Habs schon 
probiert ohne. Klappt trotzdem nicht

[Jan G. (jan80)]

Die Stromversorgung von MC ist aber ok? Kondensator vorhanden? Mal einen 
anderen MC getestet? Die können durchaus auch mal defekt sein...