This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR5889 Timer and eUSCI Interrupt Problem (with Driverlib)

Other Parts Discussed in Thread: MSP430FR5889

Hello,

I have a problem with two interrupts on my MSP430FR5889:

Timer A0 and eUSCI Module A0 are activated and get their clock both from SMCLK/DCO (8 MHz). The Timer should always count to a value in the background and call a subroutine every x seconds. The SPI-Module transmitts always a value (here 0xE7).


The software writes a byte in the TX-Buffer and enables Sleep Mode. If a byte was received, the follwing ISR is called:

#if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
#pragma vector=USCI_A0_VECTOR
__interrupt
#elif defined(__GNUC__)
__attribute__((interrupt(USCI_A0_VECTOR)))
#endif
void USCI_A0_ISR(void)
{
	switch(__even_in_range(UCA0IV,4))
	{
		case 2:
			while(!(EUSCI_A_SPI_getInterruptStatus(EUSCI_A0_BASE, EUSCI_A_SPI_TRANSMIT_INTERRUPT)));
			__bic_SR_register_on_exit(CPUOFF);
			RXedDATA = EUSCI_A_SPI_receiveData(EUSCI_A0_BASE);
			break;
		default:
			break;
	}
}

Why is the red line necessary? The following happend:

1. The programm never jumps in the while-loop.
2. If I disable the TimerA0 Interrupt, the software also works without the while-loop.
3. But when the TimerA0 Interrupt is enabled and the while-loop is missing, the SPI-Module clocks out some bytes, but suddenly the programm
remains in sleep mode.


The Timer ISR is:

#pragma vector = TIMER0_A0_VECTOR
__interrupt void Timer0_A0_ISR (void)
{
    do_anything_with_every_call_of_ISR();
    TA0CCR0 += 39999;
}

Maybe someone here had the same problem and can explain it. Why is the RX Interrupt dependent on the TimerA0 Interrupt?

Thanks

MCMajus

  • Hi MCmajus!

    Can you edit your post? Something went wrong with the formatting.
  • Hello,

    I'm sorry for the bad posting.I didn´t find a button to edit my main post, that´s why I answered my own question. I have a problem with two interrupts on my MSP430FR5889:

    Timer A0 and eUSCI Module A0 are activated and get their clock both from SMCLK/DCO (8 MHz). The Timer should always count to a value in the background and call a subroutine every x seconds. The SPI-Module transmitts always a value (here 0xE7).


    The software writes a byte in the TX-Buffer and enables Sleep Mode. If a byte was received, the follwing ISR is called:


    #if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
    #pragma vector=USCI_A0_VECTOR
    __interrupt
    #elif defined(__GNUC__)
    __attribute__((interrupt(USCI_A0_VECTOR)))
    #endif
    void USCI_A0_ISR(void)
    {
        switch(__even_in_range(UCA0IV,4))
        {
            case 2:
                while(!(EUSCI_A_SPI_getInterruptStatus(EUSCI_A0_BASE, EUSCI_A_SPI_TRANSMIT_INTERRUPT)));
                __bic_SR_register_on_exit(CPUOFF);
                RXedDATA = EUSCI_A_SPI_receiveData(EUSCI_A0_BASE);
                break;
            default:
                break;
        }
    }

    Why is the red line necessary? The following happend:

    1. The programm never jumps in the while-loop.
    2. If I disable the TimerA0 Interrupt, the software also works without the while-loop.
    3. But when the TimerA0 Interrupt is enabled and the while-loop is missing, the SPI-Module clocks out some bytes, but suddenly the programm
         remains in sleep mode.


    The Timer ISR is:

    #pragma vector = TIMER0_A0_VECTOR
    __interrupt void Timer0_A0_ISR (void)
    {
        do_anything_with_every_call_of_ISR();
        TA0CCR0 += 39999;
    }

    Maybe someone here had the same problem and can explain it. Why is the RX Interrupt dependent on the TimerA0 Interrupt?

    Thanks


    MCMajus

  • What happens if you comment out the call to do_anything_with_every_call_of_ISR() in the TimerA0 ISR?
  • @Robert Cowsill:
    Good idea. But unfortunately it does not work. Exaktly the same fault as before. Any other ideas?
  • A few questions

    -- Is you SPI a master or a slave?
    -- What happens if you enable the timer interrupt and include the while loop?
    -- Are you enabling both the TxIFG and RxIFG?
  • -- Is your SPI a master or a slave?
        It is a master


    -- What happens if you enable the timer interrupt and include the while loop?

        It works how it should and the SPI - Module pulses always new bytes out


    -- Are you enabling both the TxIFG and RxIFG?
        No, only the RxIFG, TxIFG is disabled

  • Does anybody have another idea?
    The problem still exists and I still don't know why...

    Thanks

  • This really feels like an overrun.
    What does your Tx look like exactly? Is it really as simple as "while(1){UCA0TXBUF=0xE7;LPM0;}"?
  • With the while loop, all you are doing is to wait in the loop as long as TxIFG is '0'.
    ie you are waiting until the TxIFG is set, before you wake-up the device and transmit the data.

    Without the while loop, you might be writing to the Transmit buffer before the TxIFG is set, thereby causing an erroneous data transfer.
    It is a must to anyway check the TxIFG before loading the TxBUF (else it could result in erroneous data transfer).
    Could you just replace the while loop with a delay to confirm that the delay as well causes correct transmission?

    The only question that's unclear is why is the delay (check of TxIFG) needed when Timer Interrupt is enabled (I hope no other interrupt is waking the device up to do the transmission again)
    Could you please post your complete code?