Eigenartiges Verhalten des MSP430 ( Absturz / Neustart )

[Markus M. (mmax)]

Hallo,

Ich hab immer wieder mal ein eigenartiges Verhalten meines Programmes, 
das auf einem MSP430G2553 laeuft, kompiliert mit msp-gcc. Da ich es 
schwer erklaeren kann, hab ich mal ein Video von der Ausgabe via UART 
auf der Konsole gemacht.

Das video (739KB) gibts hier:
http://www.airmax.at/uploads/msp430_hangup.avi

So wies ausschaut wird da mein Stackpointer "zerschossen" (willkuerliche 
Vermuting), auf jeden Fall startet die Mainroutine immer wieder neu, 
oder so. Ich denke mal es hat was mit sprintf und senden via UART zu 
tun, bin mir aber nicht sicher ... hat von euch jemand eine Idee?

Was fuehrt generell zu so einem Verhalten?
Kann ich das mit debuggen herausfinden?

So schaut mein main.c aus:

int main(void) {
    WDTCTL = WDTPW + WDTHOLD; // Stop WDT
    
    BCSCTL1 = CALBC1_1MHZ;    // Set "Basic clock system control 1" to 1MHz
    DCOCTL  = CALDCO_1MHZ;    // Set "DCO clock frequency control " to 1MHz
    
    P1DIR |= BIT0;
    P1OUT &= ~BIT0;
  
    // Initialize Hardware UART
    uart_init();
    
    __enable_interrupt();
    
    uart_write("\n\r-------------------------- START ------------------------------\n\r");
    
    ms5611_init();
    busy_waiting( 65000 );
    
    ms5611_read_prom();
    busy_waiting( 65000 );
    
    timer_counter = 0;
    
    TACCTL0 = CCIE;               // Set Capture/Compare interrupt enable
    TACCR0 = 4800;                // Timer a Capture/Compare register
    TACTL = TASSEL_2 + MC_2;      // Source = SMCLK (Sub-System master clock)
                                  // Mode control = MC_2 (Continuous mode)
    
    _BIS_SR(LPM0_bits + GIE);     // Enter LPM0 w/ interrupt
    
    return 0;
}

// Timer A0 interrupt service routine
#pragma vector=TIMER0_A0_VECTOR
__interrupt void Timer_A (void)
{
    if( (timer_counter%40) == 0 ) {
        sprintf( debug, "pres = %d\r\n", (int)ms5611_get_pressure() );
        uart_write(debug);
        
        P1OUT ^= BIT0;        // Hardbeat signal
        TACCR0 += 4800;       // Add Offset to CCR0
    }
    
    timer_counter++;
}

lG,
Max

[Tobias K. (kurzschluss81)]

Also ein sprintf() ist generell auf einem Microcontroller eine schlechte 
Idee.
Aber in einer ISR ist das Tödlich.

[Markus M. (mmax)]

Ich hab jetzt sprintf rausgeschmissen und mir nach Vorlage von

http://www.msp430launchpad.com/2012/06/using-printf.html

ein uart_printf gebaut. Kann man das in einer ISR verwenden oder sollte 
man darin gar nichts via UART senden?

[Dietrich L. (dietrichl)]

Markus Manninger schrieb:
> So wies ausschaut wird da mein Stackpointer "zerschossen" (willkuerliche
> Vermuting), auf jeden Fall startet die Mainroutine immer wieder neu,
> oder so.

Ja, denn wo ist die Endlosschleife in "main"? Du verlässt ja "main" mit 
"return 0;" und landest im Nirvana. Oder ist da noch was versteckt in 
einer Funktion, was man so nicht sieht?

Gruß Dietrich

[Markus M. (mmax)]

Mit "_BIS_SR(LPM0_bits + GIE);" leg ich den MC schlafen ... der Rest 
wird zyklisch in der Timer_A Routine erledigt. Das sollte so schon 
passen.

lG,
Max

[Dietrich L. (dietrichl)]

Markus Manninger schrieb:
> Mit "_BIS_SR(LPM0_bits + GIE);" leg ich den MC schlafen ... der Rest
> wird zyklisch in der Timer_A Routine erledigt. Das sollte so schon
> passen.
Aber er muss ja irgendwann wieder aufwachen, sonst tut er ja nie was.
Und wenn er aufwacht und die Timer_A Routine ausführt, dann ist er beim 
Verlassen der Routine immer noch wach und macht bei "main" weiter. Oder 
ist die Endlosschleife in "_BIS_SR(LPM0_bits + GIE);" und wird dort 
erneut schlafen gelegt?

Gruß Dietrich

[Martin (Gast)]

Markus Manninger schrieb:
> Das sollte so schon passen.

Offensichtlich nicht...
Du legst ihn zwar schlafen, aber was passiert, wenn er durch den 
Interrupt wieder aufgeweckt wird?

Pack doch einfach mal ein while(1) um Dein "_BIS_SR(LPM0_bits + GIE);".

[Markus M. (mmax)]

Das Timer wird continuierlich ausgefuehrt. Die ISR wird also immer 
wieder aufgerufen, waehrend die main angehalten ist.

Sowas funktioniert ja auch problemlos:

int main(void)
{
        WDTCTL = WDTPW + WDTHOLD;                       // Stop WDT

        BCSCTL1 = CALBC1_1MHZ;
        DCOCTL  = CALDCO_1MHZ;

        P1DIR |= BIT0;                                  // set P1.0 (LED1) as output
        P1OUT &= ~BIT0;                                 // P1.0 low

        // Configure Timer A
        TACCTL0 = CCIE;                                 // CCR0 interrupt enabled
        TACCR0 = 1000;                                  // 
        TACTL = TASSEL_2 + ID_2 + MC_3;                 // SMCLK, /4, upmode/down

        _BIS_SR(LPM0_bits + GIE);                       // Enter LPM0 w/ interrupt
        return 0;
}

// Timer A0 interrupt service routine
#pragma vector=TIMER0_A0_VECTOR
__interrupt void Timer_A (void)
{
  
        P1OUT ^= BIT0;                                  // Toggle LED
        TACCR0 += 1000;
}

[Dietrich L. (dietrichl)]

Markus Manninger schrieb:
> Das Timer wird continuierlich ausgefuehrt. Die ISR wird also immer
> wieder aufgerufen, waehrend die main angehalten ist.

Hast Du denn wenigstens mal ausprobiert, eine Endlosschleife vor das 
"return 0;" zu schreiben? Das kostet nichts.

Außerdem: es wird nicht "main" angehalten, sondern der Prozessor. Und 
wenn er durch den Interrupt wieder startet, läuft auch "main" weiter, 
wenn nach Ende der ISR und erneutem Aufruf doch eine Lücke sein sollte.

Was für ein Interrupt ist das denn überhaupt?

> Sowas funktioniert ja auch problemlos:

Auch wenn ein Programm anscheinend funktioniert, muss es nicht 
fehlerfrei sein. Ob der Fehler sichtbar wird hängt u.U. noch von vielen 
anderen Bedingungen ab.

Gruß Dietrich

[Jörg S. (joerg-s)]

Dietrich L. schrieb:
> Außerdem: es wird nicht "main" angehalten, sondern der Prozessor. Und
> wenn er durch den Interrupt wieder startet, läuft auch "main" weiter,
Nö, solange kein Exit LPM in der ISR steht, schläft er weiter.

[Dietrich L. (dietrichl)]

Jörg S. schrieb:
> Nö, solange kein Exit LPM in der ISR steht, schläft er weiter.

OK, das wusste ich nicht (ich kenne den MSP diesbezüglich nicht).

[Jörg S. (joerg-s)]

Markus Manninger schrieb:
> Ich hab jetzt sprintf rausgeschmissen und mir nach Vorlage von
> http://www.msp430launchpad.com/2012/06/using-printf.html
> ein uart_printf gebaut.
Und das macht den gleichen Fehler?

[Marc N. (Gast)]

Jetzt schreibe ein while(1) rein. Das ist doch nicht so schwer. Ich 
hasse diese renitenten Besserwisser ohne den geringsten Anteil von 
Ahnung ...

[Markus M. (mmax)]

Baue ich das Auslesen vom Temperatur und Druck des Sensors in die main() 
ein, also ganz ohne Timer Interrupt, funktioniert alles:

int main() {
 ...
    while( 1 ) {
        P1OUT ^= BIT0;
        
        uart_printf( "temp = %l\r\n", ms5611_get_temperature() );
        delay_ms( 29 );
        uart_printf( "pres = %l\r\n", ms5611_get_pressure() );
        
        delay_ms( 1000 );
    }

Ich dachte mir aber dass es ja kein Problem sein sollte das in der ISR 
zu machen, solange die Abarbeitung nicht laenger dauert wie der naechste 
Interrupt auftritt. In der ISR funktionierts auch mit der uart_pintf 
nicht.

Da die endgueltige Schaltung mit Solar betrieben werden soll, will/muss 
ich Strom sparen. Wie kann ich denn am besten jede Sekunde eine Messung 
durchfuehren ohne in einer while schleife zu loopen?

Danke,
Max

[Markus M. (mmax)]

Was aber funktioniert, ist den Timer via "TACCTL0 &= ~CCIE;" in der ISR 
zu deaktivieren, Sensor auslesen und wenn alles erledigt ist, den Timer 
via "TACCTL0 = CCIE;" wieder scharf zu schalten.

Sollte man das so machen?

[Markus M. (mmax)]

@Marc N.:
Es funktioniert auch mit einem while(1) in der main nicht!
Ich bin sicher kein Besserwisser, ganz im Gegenteil. Aber ich will Dinge 
verstehen und haette gerne eine Erklaerung weshalb was funktioniert bzw. 
nicht funktioniert.

[Jörg S. (joerg-s)]

Markus Manninger schrieb:

> Ich dachte mir aber dass es ja kein Problem sein sollte das in der ISR
> zu machen, solange die Abarbeitung nicht laenger dauert wie der naechste
> Interrupt auftritt.
Selbst wenn es länger dauert, sollte der µC trotzdem nicht abstürzen.


>Was aber funktioniert, ist den Timer via "TACCTL0 &= ~CCIE;" in der ISR
>zu deaktivieren, Sensor auslesen und wenn alles erledigt ist, den Timer
>via "TACCTL0 = CCIE;" wieder scharf zu schalten.
Das deutet natürlich auf ein Timing Problem hin. Timer kommt bevor 
letzte ISR abgeschlossen ist. Allerdings sollte das die bestehende ISR 
nicht kümmern .

Was ich mir vorstellen könnte: Die UART Routine soll das letzte Byte 
ausgeben, das wird in den Buffer übertragen, die UART Routine wartet 
aber nicht bis es fertig übertragen worden ist und kehrt in die ISR 
zurück die gleich wieder in die main und somit in den LPM springt und 
die Ausgabe des letzten Bytes abwürgt.

Hast du eigentlich kein Debugger? Dann kannst du dir doch wunderschön 
ansehen was passiert.


Was sollen die Zeilen:
TACCR0 += 4800;
und
((timer_counter%40) == 0 )
bewirken?

[Martin (Gast)]

Markus Manninger schrieb:
> Was aber funktioniert, ist den Timer via "TACCTL0 &= ~CCIE;" in der ISR
> zu deaktivieren, Sensor auslesen und wenn alles erledigt ist, den Timer
> via "TACCTL0 = CCIE;" wieder scharf zu schalten.

Markus Manninger schrieb:
> Ich dachte mir aber dass es ja kein Problem sein sollte das in der ISR
> zu machen, solange die Abarbeitung nicht laenger dauert wie der naechste
> Interrupt auftritt.

Bist Du Dir sicher, dass dem so ist?

Bist Du Dir wirkich sicher, dass Dein Prozessor nicht doch aufwacht, an 
das Ende der Main kommt und seltsame Sachen macht (z.B. einen Reset oder 
den PC komplett durchzählen, irgendwelchen Müll dabei machen und dann 
wieder von vorne anfangen...)

[Tobias K. (kurzschluss81)]

Ich würde dir mal dieses Dokument empfehlen um den Umgang mit ISR 
Sleepmode und ähnlichem anzulesen
http://www.ti.com/lit/an/slaa294a/slaa294a.pdf
Da geht es um MSP430 Software Coding Techniques

[Markus M. (mmax)]

Jörg S. schrieb:
> Was ich mir vorstellen könnte: Die UART Routine soll das letzte Byte
> ausgeben, das wird in den Buffer übertragen, die UART Routine wartet
> aber nicht bis es fertig übertragen worden ist und kehrt in die ISR
> zurück die gleich wieder in die main und somit in den LPM springt und
> die Ausgabe des letzten Bytes abwürgt.
>
> Hast du eigentlich kein Debugger? Dann kannst du dir doch wunderschön
> ansehen was passiert.

Davor hab ich mich bis jetzt gedrueckt ... werd mich aber mit dem 
mspdebug wohl beschaeftigen muessen.

> Was sollen die Zeilen:
> TACCR0 += 4800;

Ich befuerchte das ist eh um sonst, da der Timer immer bis FFFFh zaehlt 
und dann feuert, da ich den MC_2 mode benutze.

> ((timer_counter%40) == 0 )

Naja, damit fuehre ich den Code innerhalb der if Abfrage nur jeden 40ten 
ISR Aufruf aus. Auch nicht sehr schoen, ich weiss. Aber ich bekomm mit 
1MHz Clock keine vernueftige Sekunde zusammen. Werd aber in Zukunft eh 
mit 32kHz takten.

Gibts eigentlich eine Moeglichkeit zu zaehlen wieviele CPU cycles 
zwischen zwei Iterationen (Codestellen) vergangen sind?

[auf die schnelle (Gast)]

TACCR0 += 4800;       // Add Offset to CCR0

Das muss außerhalb der if Bedingung stehen. Sonst fehlt der Wert für den 
nächsten compare.

[wk (Gast)]

Hi,
wie sieht denn dein UART printf aus?
Verwendest du UART interrupts?

grüße

[mmax (Gast)]

Ich hab das printf via UART von

http://www.msp430launchpad.com/2012/06/using-printf.html

übernommen. Denke dass sprintf auf einem MC nicht so gut ist, mit dem 
uart_printf funktionierts recht gut ... aber das Hauptproblem war, dass 
ich innerhalb der Timer ISR den Timer nicht angehalten hab. Seitdem ich 
das mache, funktioniert auch alles soweit.

[Markus M. (mmax)]

So, jetzt hab ichs glaub ich recht sauber umgesetzt. In der while() leg 
ich den MC schlafen und setz vorher den Timer, der den MC wieder 
aufweckt. Simple und wie von TI empfohlen

int main(void) {
    WDTCTL = WDTPW + WDTHOLD; // Stop WDT
    
    BCSCTL1 = CALBC1_1MHZ;    // Set "Basic clock system control 1" to 1MHz
    DCOCTL  = CALDCO_1MHZ;    // Set "DCO clock frequency control " to 1MHz
    
    P1DIR |= BIT0;
    P1OUT &= ~BIT0;

    // Configure TimerA0
    TACTL = TASSEL_2 | ID_3 | MC_3;   // Source = SMCLK (Sub-System master clock)
                                      // Mode control = MC_1 (Up mode)
    
    while( 1 ) {
        TACCR0  = 62500;          // Add Offset to CCR0
        TACCTL0 = CCIE;           // Start timer interrupt
        _BIS_SR(LPM0_bits + GIE); // Enter LPM0 w/ interrupt
        
        P1OUT ^= BIT0;
    }

    return 0;
}

// Timer A0 interrupt service routine
#pragma vector=TIMER0_A0_VECTOR
__interrupt void Timer_A (void)
{
    _BIC_SR_IRQ(LPM0_bits);
}

Mich wunderst nur dass mein LED nicht "genau" im 1 Sekunden Takt blinkt. 
Bei 1MHz Tankt, 1/8 Teiler (ID_3), Up- Down Mode (MC_3) und TACCR0  = 
62500 muesste ich da doch einigermassen hinkommen. 62500 x 8 x 2 = 
1000000, oder was versteh ich da falsch?

Und gibts keine Moeglichkeit zwischen zwei Durchlauefen in der while 
Schleife die Anzahl der CPU Ticks auszulesen?

[auf die schnelle (Gast)]

Die Aktualisierung des Timers muss in der ISR erfolgen.

Vergiss vorerst die Sache mit dem Low Power Mode. Das kannst du später 
noch nachholen.

Dietrich L. schrieb:
> Und wenn er aufwacht und die Timer_A Routine ausführt, dann ist er beim
> Verlassen der Routine immer noch wach und macht bei "main" weiter.
Nein, der Power Mode steht im PSW und wird mit dem RETI restauriert. Es 
wird kein weiterer Befehl im Hauptprogramm ausgeführt. Man findet viele 
Programmbeispiele für den MSP ohne Endlosschleife.

[Jörg S. (joerg-s)]

Markus Manninger schrieb:
> Mich wunderst nur dass mein LED nicht "genau" im 1 Sekunden Takt blinkt.
Wie blinkt er denn?


> Und gibts keine Moeglichkeit zwischen zwei Durchlauefen in der while
> Schleife die Anzahl der CPU Ticks auszulesen?
Nein. Dafür kannst du Timer nutzen ;)

[Markus M. (mmax)]

Jörg S. schrieb:
> Markus Manninger schrieb:
>> Mich wunderst nur dass mein LED nicht "genau" im 1 Sekunden Takt blinkt.
> Wie blinkt er denn?

Naja, nicht ganz genau eine Sekunde. Das passt aber schon.

>> Und gibts keine Moeglichkeit zwischen zwei Durchlauefen in der while
>> Schleife die Anzahl der CPU Ticks auszulesen?
> Nein. Dafür kannst du Timer nutzen ;)

Schade, das waere sehr praktisch.

[Jörg S. (joerg-s)]

Markus Manninger schrieb:
> Schade, das waere sehr praktisch.
Der Timer macht ja genau das was du dir davon versprichst.

[auf die schnelle (Gast)]

So, mal auf die schnelle aufs launchpad gepackt:

#include "io430g2553.h"

typedef unsigned char     uint8_t;
typedef unsigned int      uint16_t;

volatile uint16_t ticks = 0;

void main( void )
{
    // stop watchdog timer to prevent time out reset
  WDTCTL = WDTPW + WDTHOLD;
   // clock source DCO, set to 1MHz
  BCSCTL1 = CALBC1_1MHZ;
  DCOCTL = CALDCO_1MHZ;
   // init port
  P1DIR |= BIT0;                        // Set P1.0 to output direction
   // WDT Timer 8ms
  WDTCTL = WDT_MDLY_8;
   // enable interrupts
  IE1 |= WDTIE;
  __enable_interrupt();
  while(1)
  {
     // do something
    if(ticks % 2) P1OUT |= BIT0;
    else P1OUT &= ~BIT0;
  }
}

 //Watchdog Timer interrupt service routine
#pragma vector=WDT_VECTOR
__interrupt void WDT_ISR (void)
{
  static uint8_t count = 0;
  if(count++ >= 125)
  {
    count = 0;
    ticks++;
  }
}

Anstatt Timer A habe ich den WDT genommen.