MSP430 ISR - kehrt nicht richtig zurück

[Dominik S. (sleepingiq)]

Hi
hab folgendes Problem.
Hab einen MSP430F169 bei welchem ich USART0 im UART modus initialisire 
und ihn dann in den LMP3 schicke. Nun habe ich eine rx_isr realisirt die 
ein einfaches Echo macht. Wenn ich nun beim Debuggen per Step 
durchlaufen lasse, funktioniert es einmalig. Leider kehrt der MSP nach 
dem ersten durchlaufen der ISR nicht mehr zurück sondern läuft ins 
Nirwana. Ich weiß jetzt nicht mehr weiter kann mir vielleicht jemand 
einen Hinweis geben woran es liegen könnte.
Danke im vorraus
Sleeping IQ

PS: Code kann ich gerade nicht posten. Habe aber die selbe ISR bei einem 
MSP430F1611 schon erfolgreich verwendet

[Christian R. (supachris)]

Ohne Code kann man nur spekulieren. LPM3 und UART...hmm...dann nur mit 
dem ACLK als UART Takt ja?

[Dominik S. (sleepingiq)]

Hi
Ja hab den ACLK alls Takt verwendet. Was mich halt am meisten wundert 
ist das es beim anderen MSP problemlos funktioniert hat.

[Dominik S. (sleepingiq)]

Hi so habe jetzt den Code!
hab noch ein Bild angehängt dort erscheint nach aufruf der ISR noch ein 
thread mit dem Namen _reset_vector() ich versteh aber nicht wirklich wo 
der eigentlich auf einmal herkommt.


#include "msp430x16x.h"

__interrupt void uart_rx(void);
void empty(void);
void null(void);


void main (void)
{
  WDTCTL = WDTPW + WDTHOLD;

  P3DIR |= 0x80; // P3.7 wird output

  P3SEL = 0x30;
  TXBUF0 = 0x00;
  ME1 |= UTXE0 + URXE0;
  UCTL0 |= CHAR;
  UTCTL0 |= SSEL0;  //Clock ACLK!
  UBR00 = 0x03;
  UBR10 = 0x00;
  UMCTL0 = 0x4A;
  UCTL0 &= ~SWRST;
  IE1 |= URXIE0 + UTXIE0;
  IFG1 &= ~UTXIFG0;

  P3OUT |= 0x80; // P3.7 auf high /empfangsbereit
  //empty();
  _BIS_SR(LPM3_bits + GIE);


}

USART0RX_ISR(uart_rx)
__interrupt void uart_rx(void)
{
  P3OUT &= 0x3F; // P3.7 auf low /nicht empfangsbereit ( könnte auch &= 
~0x80
  //while (!(0x40==(P3IN&0x40))); // warten das Gegenstelle 
empfangsbereit ist.
  while (!(UTXIFG0));
  TXBUF0 = RXBUF0;
  P3OUT |= 0x80; // P3.7 auf high /empfangsbereit
}

void empty(void)
{
}

[Christian R. (supachris)]

Typischer Anfängerfehler. Du setzt das Bit für den TX-Interrupt, hast 
aber keine ISR dazu. Wenn das Byte fertig gesendet ist, gibts den Int 
und der MSP läuft ins Nirvana.

[Dominik S. (sleepingiq)]

Hi
hab jetzt das Tx Interrupt Bit disabled. Leider besteht das Problem 
immer noch. Ich befürchte das das Problem schon beim starten der RxISR 
entsteht. Wenn man auf dem Bild schaut welches ich im Post vorher 
angehängt habe sieht man das dieser ominöse "_reset_vector()" schon beim 
starten der RxISR erscheint. Leider habe ich nicht wirklich eine Ahnung 
was dieser macht und vorallem wo er herkommt. Bin inzwischen ziemlich 
frustriert.

[Christian R. (supachris)]

Der Reset-Vektor wird beim Start des µC ja immer angesprungen. Abhängig 
vom Sonnenstand, Außentemperatur, IP-Nummer XOR Kaffee-Füllstand meiner 
Tasse zeigt den Eclipse bei mir auch immer mal an und immer mal nicht. 
Daran wird´s nicht liegen.

[Dominik S. (sleepingiq)]

Hi
ich glaub ich hab das Problem gefunden (Noch keine Lösung). Die Adresse 
an welche der Stack Pointer schreibt und liest ist voller F's. Für mich 
bedeutet dies das der Stack nicht beschrieben wird. Woran kann das 
liegen und was kann ich dagegen machen??

[Dominik S. (sleepingiq)]

Hi
Problem gelöst!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Die Ursache war ein falsches Link-File.
Dies kam daher das ich das alte Projekt verwendet habe welches für den 
1611 war. Man kann zwar in den Projekt Einstellungen den µC Typ 
verstellen aber es wird nicht das Link-File geändert in welchem die 
Speicherbereiche stehen somit hat mein Stackpointer an eine Stelle 
gezeigt in welche er nicht schreiben darf.
Ziemlich blöder Fehler aber aus sowas lernt man.
Danke dir Christian für deine Hilfe.

[Christian R. (supachris)]

Seit wann wird das Linker-File nicht geändert? Bei mir macht der das, 
wenn ich in den Projektoptionen bei Compiler und Linker den µC Typ 
ändere. Komisch.

[Dominik S. (sleepingiq)]

Hi
hab den µC Typ unter Project->Properties->Debug Properties->Device 
geändert. Kann auch sein das ich es mir mit diesem Vorgehen dann doch zu 
einfach gemacht habe.