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.
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