[PIC18F] Lokale Variablen nach Interrupt-Return vermatscht

[Enrico K. (ekoeck)]

Hallo!

Ich habe ein sehr schwierig einzuordnendes Problem mit einem PIC18F252 
(MPLAB X IDE v2.00, XC8 v1.34). Folgende Routine gibt mir 16Bit-Zahlen 
zu Debugging-Zwecken auf der UART-Schnittstelle aus. Nach einer 
unbestimmten Zeit (ca. 20 sek, kann nicht genau sagen, ob regelmäßig) 
fängt der Output an kryptisch zu werden (siehe konsole.png). Durch ewige 
Sucherei habe ich endlich herausgefunden, woher der Datenmüll kommt, 
kann mir aber absolut nicht erklären, warum dies so ist. Datenmüll tritt 
auf, wenn der Interrupt in die Routine zur Ausgabe der Zeichen zurück 
springt. Dann haben sich aus mir unerklärlichen Gründen die Werte der 
lokalen Variablen geändert (siehe buf.png, number.png, dez.png). Dass in 
"dez[4]" jetzt komplett andere Werte stehen als bei der Initialisierung 
der Variablen geht mir einfach nicht in den Kopf. Ebenfalls, dass in buf 
(angelegt zu Debugging-Zwecken) noch der Wert steht, welchen "number" 
zum Funktionsaufruf hatte, jetzt aber in "number" ein kompletter 
Mondwert (ja, verändert sich, dürfte aber nur kleiner werden) steht.
Wenn ich die Funktion mit deaktivierten Interrupts laufen lasse und 
immer einen um Eins erhöhten uint16 füttere, läuft alles problemlos.

Hat jemand eine Anregung für mich, woher das Problem kommen könnte? Ich 
bin kurz davor das Programm anders aufzubauen, dies befriedigt aber 
meiner Neugier nicht.

Schonmal vielen Dank im Vorraus!

Problematische Funktion:

void UARTputUint16(uint16_t number)
{
    /* description: send a decimal number over the serial port
     * parameters:  -
     * returns:     -
     */

    uint16_t dez[4] = {10000, 1000, 100, 10};
    uint8_t cnt, i;
    uint16_t buf = number;

    // int16 <= 65535 -> maximum 5 decades
    for (i = 0; i < 4; i++)
    {
        cnt = '0';

        // subtract decade as long as it fits
        while (number >= dez[i])
        {
            number -= dez[i];
            cnt++;
        }

        // output the digit
        UARTputChar(cnt);
    }

    if (number > 9)
    {
        NOP();
        buf += 0;
    }

    UARTputChar(number + '0');
}

UARTputChar:

void UARTputChar(char c)
{
    /* description: send a character over UART and wait for buffer to clear
     * parameters:  c - character to be sent
     * returns:     -
     */
    TXREG = c;

    // wait untin sending buffer is empty
    while(PIR1bits.TXIF == 0)
    {
        NOP();
    }
}

Im Interrupt wird ein Flag gesetzt (_ACflag), welches dann in der Main 
gepollt wird und die problematische Ausgabe aufruft.
ISR:

void interrupt ISR()
{
    /* description: interrupt service routine
     * parameters:  -
     * returns:     -
     */

    // if port change interrupt on PORTB

    if (INTCONbits.RBIE && INTCONbits.RBIF && (PORTBbits.RB4 == 1))
    {
        INTCONbits.RBIF = 0;    // clear interrupt flag

        T3CONbits.TMR3ON = 0;   // stop timer
        _periodTime = (TMR3H << 8) + TMR3L; // save period time
        TMR3H = 0;
        TMR3L = 0;
        //_laststate = HIGH;
        T3CONbits.TMR3ON = 1;   // start timer again
    }

    if (PIE1bits.CCP1IE && PIR1bits.CCP1IF)
    {
        PORTBbits.RB3 = !PORTBbits.RB3;

        // clear interrupt flag
        PIR1bits.CCP1IF = 0;

        if (PORTCbits.RC2 == 1)
        {
            // next interrupt with falling edge
            CCP1CONbits.CCP1M = 0b0100;

            _xTimeUp = (CCPR1H << 8) + CCPR1L;
        }
        else
        {
            // first interrupt with rising edge
            CCP1CONbits.CCP1M = 0b0101;

            _xTimeDn = (CCPR1H << 8) + CCPR1L;

            uint16_t xPeak = (_xTimeUp + _xTimeDn) >> 1;
            uint16_t xPforth = _periodTime >> 2;

            if (_xTimeUp > _xTimeDn)
            {
                _phaseTime = xPeak - xPforth;
            }
            else
            {
                _phaseTime = xPeak + xPforth;
            }

            _ACflag |= 0x01;
        }
    }
    INTCONbits.GIE = 1;
}

main:

void main()
{    
    iniSys();
    
    iniUART();

    iniTimer3();

    INTCONbits.GIE = 1; // global interrupts
    INTCONbits.PEIE = 1; // peripheral interrupts

    PORTBbits.RB0 = 1;

    while(1)
    {
        while (_ACflag == 0);

        _ACflag = 0;
        UARTputUint16(_phaseTime); UARTputChar(10); UARTputChar(13);
    }
}

[Peter II (Gast)]

Enrico Koeck schrieb:
> Hat jemand eine Anregung für mich, woher das Problem kommen könnte?

vermutlich ein Speicherüberschreiber irgendwo im code. Oder wenn sich 
die Funktionen gegenseitig aufrufen, ein Stack überlauf.

[Little B. (lil-b)]

Lass dir mal das Disassembly deiner ISR und deiner Uart Ausgabe 
anzeigen. Vieleicht siehst du dann, welcher Speicher tatsächlich von den 
jeweiligen Funktionen verwendet wird.

Mich verwirrt dieses Phänomen, da du in der ISR defacto keine Stack 
Variablen hast.

Disassembly zu finden unter Window->Debug->Disassembly oder so...

[Klaus (Gast)]

Enrico Koeck schrieb:
> INTCONbits.GIE = 1;

Du gibst den Interrupt innerhalb der ISR frei, das könnte das Problem 
sein.

Und warum machst du das:

Enrico Koeck schrieb:
> // wait untin sending buffer is empty
>     while(PIR1bits.TXIF == 0)
>     {
>         NOP();
>     }

Das UART macht das Senden auch ohne daß du wartest. Erst wenn ein neues 
Byte gesendet werden soll braucht man zu schauen, ob dafür Platz ist.

Little Basdart schrieb:
> Lass dir mal das Disassembly ...

Der C-Debugger zeigt doch die Adressen direkt an

MfG Klaus

[Enrico K. (ekoeck)]

!    uint16_t dez[4] = {10000, 1000, 100, 10};
0x618: LFSR 2, 0x30
0x61A: NOP
0x61C: LFSR 1, 0x1C
0x61E: NOP
0x620: MOVLW 0x8
0x622: MOVFF POSTINC2, POSTINC1
0x624: NOP
0x626: DECFSZ WREG, F, ACCESS
0x628: BRA 0x622
!    uint8_t cnt, i;
!    uint16_t buf = number;
0x62A: MOVFF number, buf
0x62C: NOP
0x62E: MOVFF config, 0x1B
0x630: NOP

Das Problem hat sich jedenfalls in Luft aufgelöst, wenn ich das Array 
dez[4] als globales

const uint16_t dez[4]

 anlege, was auch sinnvoller ist. So ein wenig fader Beigeschmack bliebt 
aber trotzdem zurück ^^

[Peter II (Gast)]

Enrico Koeck schrieb:
> Das Problem hat sich jedenfalls in Luft aufgelöst, wenn ich das Array
> dez[4] als globalesconst uint16_t dez[4] anlege, was auch sinnvoller
> ist. So ein wenig fader Beigeschmack bliebt
> aber trotzdem zurück ^^

richtig, aus dem Grund würde ich es fehlerhaft lassen und lieber den 
Fehler suchen.

[Peter D. (peda)]

Enrico Koeck schrieb:
> Das Problem hat sich jedenfalls in Luft aufgelöst

Nö.
Globale und lokale Variablen werden einfach nur an verschiedene Stellen 
gelinkt.
D.h. der Fehler verändert jetzt ne andere Variable oder mit etwas Glück 
noch ungenutzten RAM.

[Little B. (lil-b)]

Klaus schrieb:
> Little Basdart schrieb:
>> Lass dir mal das Disassembly ...
>
> Der C-Debugger zeigt doch die Adressen direkt an

Das ist auch so weit richtig, jedoch nur die Adressen der Variablen. Da 
der PIC aber nur ein Work Register hat, müssen Zwischenergebnisse ins 
RAM geschrieben werden. Diese Adressen werden nicht angezeigt und sieht 
man nur im Disassembly.

[Enrico K. (ekoeck)]

Also das Problem hat in irgendeiner Art und Weise damit zu tun, dass der 
Portchange-Interrupt und der Capture-Interrupt sich gegenseitig 
verhaken.. Ich habe jetzt meinen Algorithmus angepasst und den Code 
komplett umgeschrieben, sodass dies jetzt nicht mehr vorkommen kann. 
schulterzuck
Vielen Dank für die Anregungen!

[Mike (Gast)]

In der ISR vermisse ich das Rücksetzen der Inetrrupt-Flags!
Sobald GIE wieder gesetzt wird, wird der Interrupt erneut aufgerufen. 
Durch die vielfache Verschachtelung der Aufrufe läuft der Stack über, 
was vermutlich zum Reset führt. Das explizite Setzen des GIE ist ohnehin 
unnötig, da der PIC das am Ende der ISR über RETFIE automatisch macht!

Gruss
Mike

[Mike (Gast)]

Sorry, ich habe das Rücksetzen der IF-Flags übersehen. Trotzdem würde 
ich die Zeile

INTCONbits.GIE = 1;

 mal auskommentieren, weil das zur Verschachtelung der Interruptaufrufe 
führen kann.

[Enrico K. (ekoeck)]

Okay, das GIE hab ich mal rausgenommen, wusste nicht genau, ob das 
automatisch gesetzt wird. Die Interruptflags werden immer gleich nach 
der Abfrage, welcher Interrupt kam, gelöscht.