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.

MSP430FR2433: SPI Slave not generating interrupts but works in polling mode

Part Number: MSP430FR2433
Other Parts Discussed in Thread: MSP-EXP430FR2433

Hello,

I am new to MSP430s and trying to figure out how to setup MSP430FR2433 as a slave (in loop back mode to verify operation). I am using MSP-EXP430FR2433 Dev kit.

Using example code from SLAC700e (msp430fr243x_euscia0_spi_10.c), loopback fails.

example code from SLAC700e:

#include <msp430.h>

int main(void)
{
WDTCTL = WDTPW|WDTHOLD; // Stop watchdog timer

P1SEL0 |= BIT4 | BIT5 | BIT6; // set 3-SPI pin as second function

UCA0CTLW0 |= UCSWRST; // **Put state machine in reset**
UCA0CTLW0 |= UCSYNC|UCCKPL|UCMSB; // 3-pin, 8-bit SPI slave
// Clock polarity high, MSB
UCA0CTLW0 |= UCSSEL__SMCLK; // SMCLK
UCA0BR0 = 0x01; // /1, fBitClock = fBRCLK/UCBRx
UCA0BR1 = 0; //
UCA0MCTLW = 0; // No modulation
UCA0CTLW0 &= ~UCSWRST; // **Initialize USCI state machine**
UCA0IE |= UCRXIE; // Enable USCI_A0 RX interrupt

PM5CTL0 &= ~LOCKLPM5; // Disable the GPIO power-on default high-impedance mode
// to activate previously configured port settings

__bis_SR_register(LPM0_bits | GIE); // Enter LPM0, enable interrupts
}

#if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
#pragma vector=USCI_A0_VECTOR
__interrupt void USCI_A0_ISR(void)
#elif defined(__GNUC__)
void __attribute__ ((interrupt(USCI_A0_VECTOR))) USCI_A0_ISR (void)
#else
#error Compiler not supported!
#endif
{
while (!(UCA0IFG&UCTXIFG)); // USCI_A0 TX buffer ready?
UCA0TXBUF = UCA0RXBUF; // Echo received data
}

Output from master:

00 00

00 00

00 00

00 00

But in polling mode, the slave works just fine:

#include <msp430.h>
unsigned char RXData0 = 0;
unsigned char RXData1 = 0;
unsigned char TXData = 0xAA;
unsigned char counter = 0;

int main(void)
{
WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer

P1SEL0 |= BIT4 | BIT5 | BIT6; // set 3-SPI pin as second function

UCA0CTLW0 |= UCSWRST; // **Put state machine in reset**
UCA0CTLW0 |= UCSYNC | UCCKPL | UCMSB; // 3-pin, 8-bit SPI slave
// Clock polarity high, MSB
UCA0CTLW0 |= UCSSEL__SMCLK; // SMCLK
UCA0BR0 = 0x01; // /1, fBitClock = fBRCLK/UCBRx
UCA0BR1 = 0; //
UCA0MCTLW = 0; // No modulation
UCA0CTLW0 &= ~UCSWRST; // **Initialize USCI state machine**
UCA0IE |= UCRXIE; // Enable USCI_A0 RX interrupt

PM5CTL0 &= ~LOCKLPM5; // Disable the GPIO power-on default high-impedance mode
// to activate previously configured port settings

// __bis_SR_register(LPM0_bits | GIE); // Enter LPM0, enable interrupts
while (1)
{
if (UCA0IFG & UCRXIFG)
{
if (counter == 0)
{
RXData0 = UCA0RXBUF;
while (!(UCA0IFG & UCTXIFG))
;
UCA0TXBUF = RXData0;
counter = 1;
}
else
{
RXData1 = UCA0RXBUF;
while (!(UCA0IFG & UCTXIFG))
;
UCA0TXBUF = RXData1;
counter = 0;
}
}
}

}

Output from master:

00 00

11 AA

12 AB

13 AC

14 AD

15 AE

16 AF

17 B0

18 B1

19 B2

I know the interrupt flag is enabled. I dont know why the ISR is never called. Any suggestions would be appreciated!

Thanks

Gaurav 

  • Hi GauravS,

    Try writing the first byte to the TXBUF before entering the low power mode.

  • Hello Dennis,

    Thanks for the suggestion. 

    This is really stupid, but I came back this morning and in order to try your suggestion, I recomplied the example from above and to my surprise, the original example is working like a charm now. Apologize for wasting everyone's time. I have no clue what the problem was or how it resolved itself!

    Thanks

    Gaurav

  • It used to be (probably still is) that the FR2433 Launchpad came pre-loaded with a demonstration program which used the RTC. Loading a new program with the debugger doesn't reset the RTC (that's a feature), so the new program would, after a second or so, end up mysteriously at FaultISR.

    This symptom would persist through multiple program loads until the user (someone like me) got frustrated and pulled out the USB -- power-cycling the chip does reset the RTC.

    I don't know whether that was your case, but it's one way to get Irreproducible Results with a new Launchpad.

  • Thanks Bruce! So I haven't completely lost my marbles after all, phew.

    On a more serious note, this launch pad is not exactly new and has passed through multiple pairs of hands. I was messing around with the rtc example code yesterday and did not unplug the USB until the end of the day. I wonder any rtc instance can trigger mysterious faulty isr? Can this issue occur on production boards or is it limited to this eval board only? 

  • The hazard is in the chip, not the board, but it only appears if you (a) load a program which uses the RTC (in particular RTCIE) then (b) load a different program which doesn't.

    As a practical matter, I expect this sequence rarely happens on production boards. By contrast, loading a very-different program is probably the first thing anyone does with a new Launchpad.

    And the alternative -- have a PUC reset stop the RTC -- would be a big loss of function.

  • Thanks for the clarification. A good rule of thumb would be to clear RTCIE on startup to avoid this situation?

  • Yes, you could start every program with "RTCCTL=0;". I found that just being aware that it can happen was adequate.

**Attention** This is a public forum