PIC18 mit MCC18 Problem mit TableRead

[Matthias P. (Firma: privat) (sogge)]

Hi Leute,

habe seit Tagen ein Problem und finde den Fehler einfach nicht.

Es handelt sich um eine einfache Text Ausgabe an einem LCD.

Das Gerät läuft über Stunden und Funktioniert.
Irgendwann nach X-Stunden wenn die Funktion LcdPrintString() aufgerufen 
wird, kommt das Programm nicht mehr über die while(tempChar) bedingung 
"drüber". Da nach tempChar = s[x]  0x00 in tempChar steht.

Obwohl ich beim Debuggen an der Stelle s[x] einen gültigen ASCII sehe.

Ich kenne mich leider im ASM nicht "so" gut aus.
Aber ich glaube das Problem liegt im Bereich

0xB626: TBLRD*
0xB628: MOVLW 0x4
0xB62A: MOVFF TABLAT, PLUSW2

Ich glaube das es was mit dem TBLRD* zu tun hat.
Obwohl ich nicht genau verstehe was er da exakt macht (Table Read).
Ich vermute das er an dieser Stelle das Byte an der Adresse von (TBLPTRH 
und TBLPTRL) lesen will.
Diese Beiden Pointer TBLPTRH+TBLPTRL haben aber die richtige Addresse 
vom Speicherort, wo auch das ASCII Zeichen stehen soll (was es auch tut 
laut Speicher Beobachtung)


Was ich einfach nicht verstehe ist das, dass Programm über Stunden 
funktioniert und auf einmal den CHAR nicht mehr aus dem "speicher" lesen 
kann.

Bitte um Hilfe!


µC: Pic18F8722
Compiler: mcc18 v3.46
Umgebung: MPLAB X 1.95


//C-Funktion

void LcdPrintString(const rom char *s,
                      unsigned char positionX,
                      unsigned char positionY,
                      unsigned char FontStyle,
                      unsigned char offset)
{
    
    int i=0,x=0;
    char tempChar=0;

    tempChar = s[x];
    
    while(tempChar)
    {
      blabla schreibe s[x] an display
    c++
    }
}

//Funktion in ASM Code//

!    tempChar = s[c];
0xB60A: MOVLW 0x2
0xB60C: MOVFF PLUSW2, __tmp_0
0xB60E: NOP
0xB610: MOVLW 0x3
0xB612: MOVFF PLUSW2, digit_cnt
0xB614: NOP
0xB616: MOVLW 0xFD
0xB618: MOVF PLUSW2, W, ACCESS
0xB61A: ADDWF __tmp_0, W, ACCESS
0xB61C: MOVWF TBLPTRL, ACCESS
0xB61E: MOVLW 0xFE
0xB620: MOVF PLUSW2, W, ACCESS
0xB622: ADDWFC digit_cnt, W, ACCESS
0xB624: MOVWF TBLPTRH, ACCESS
0xB626: TBLRD*
0xB628: MOVLW 0x4
0xB62A: MOVFF TABLAT, PLUSW2
0xB62C: NOP
!    while(tempChar)
0xB62E: MOVLW 0x4
0xB630: MOVF PLUSW2, W, ACCESS
0xB632: BNZ 0xB636                <---- Springe an richtige stelle 
0xB634: BRA 0xB730                <---- Springe raus da kein Char vorhanden
0xB72E: BRA 0xB62E

[Matthias P. (Firma: privat) (sogge)]

Ach ja.
Wenn ich das Gerät Aus/Ein Schalte dann läuft er erneut für X-Stunden 
und der Fehler kommt erneut

[Max H. (hartl192)]

Matthias P. schrieb:
> blabla schreibe s[x] an display
>     c++
Wie wärs mit einem vollständigen Code?
Zum Beispiel den Inhalt der while();


> tempChar = s[x];
>
>     while(tempChar)
>     {
>       blabla schreibe s[x] an display
>     c++
>     }
Wenn  s[x] != 0 und  "tempChar" in der while nicht geändert wird, wird 
die Schleife für immer laufen.

[Matthias P. (Firma: privat) (sogge)]

ist doch völlig schnuppe was in der While() steht.
Er kommt ja garnicht rein da in TempChar anscheinend 0x00 steht wo 
eigentlich ein ASCII geladen wird (der ja auch an der stelle s[x] steht.

Bin mir mittlerweile ziemlich sicher das es am ASM-Befehel

0xB626: TBLRD*
0xB628: MOVLW 0x4
0xB62A: MOVFF TABLAT, PLUSW2

liegt.

Da er an einer anderen Stelle im Code, im Fehlerfall, nach dem TBLRD* im 
register TABLAT nichts steht. Obwohl dort etwas stehen sollte.

Sollte ja dann ein Controller Fehler sein oder ??? evtl Compiler?

Ist dieser Fehler irgend jemandem bekannt? Hab dazu nichts gefunden.

Oder weiß jemand wie man diesen Fehler beheben kann?

[Dieter Werner (Gast)]

Zeigt denn der TBLPTR vor dem TBLRD* auf die richtige Adresse im 
Flash?

[Matthias P. (Firma: privat) (sogge)]

Das kann ich jetzt gerade nicht mit 100% sicherheit sagen (da gerade 
kein Fehler anliegt) aber ich glaube ja.

Was wäre wenn nicht?

die Register TBLPTRL und TBLPTRH haben aber sicher die richtige Addresse 
im Bauch

[Matthias P. (Firma: privat) (sogge)]

Ich könnte mir hald vorstellen das ich irgendwo im Programm mir den 
TBLPTR kaputt mache. Die frage ist nur wie ich das mache ^^
Da ja bei einem Chipreset (im debugg oder spg aus/ein) wieder alles 
läuft für x-Stunden