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.

MSP430FR2355: eUSCI --- comm between two EVM --- LPM3 issue

Part Number: MSP430FR2355

Good morning.....

I have two MSP430FR2355EVM that are wired together....I have TX of one board wired to RX of the other.  I can see the data stream (6 characters) from the TX pin on a logic analyzer at the RX board, however I cannot seem to capture the stream in code.  I have the RX board on the debugger and am getting interrupts.  On the TX board the 16MHz clock is being produced the whole period that the six characters are on the bus HOWEVER on the RX side the 16MHz is bursting during the attempt at receive (I am trying to use LPM3).  If I put the RX side into LPM0 all is fine. Can someone please tell me what I need to do to have the RX side clock run during the whole time the board is receiving and then go into LPM3?

#include <msp430.h>
#include "rc.h"

char rcv[6] = {0}, *prcv;

int main(void)
{
    WDTCTL = WDTPW | WDTHOLD;   // stop watchdog timer
    prcv = rcv;
    IOconfig;
    initClockTo16MHz();
    initUART();
    P6DIR |= BIT6;
    __bis_SR_register(LPM0_bits + GIE); //go to sleep: LPM3
}

#pragma vector=USCI_A1_VECTOR
__interrupt void Payload_RF(void)
{
    switch(__even_in_range(UCA1IV, USCI_UART_UCTXCPTIFG))
    {
      case USCI_NONE: break;
      case USCI_UART_UCRXIFG:
          UCA0IFG &=~ UCRXIFG;
          *(prcv) = UCA1RXBUF;
          prcv++;
          __bic_SR_register_on_exit(LPM0_bits);
          break;

      case USCI_UART_UCTXIFG: break;
      case USCI_UART_UCSTTIFG: break;
      case USCI_UART_UCTXCPTIFG: break;
    }
}

  • Hi Steve,

    I suspect what is happening on the receiver side is in LPM3 it takes some time for the clocks to back up and settle before the baud rate clock is available.  Meanwhile, the master is sending bytes and probably the first byte is generating a framing error.  In LPM0, only the CPU is stopped; the clocks remain on.

    In the datasheet, pg32, it shows a 10us startup time just to bring the CPU out of reset and start executing code.

    I don't know what baud rate you are using but lets say it 9600.  The bit-rate period is 104us and may not be an this issue.  However, let's say you are running at 115200.  Now the bit rate period is 8.6us, so you can easily miss a bit, so the UART only sees 7 bits, not 8bits on the first byte that is sent.

    There is no way to speed up the clock system to work around this.

    Just as a comment - our MSP430 CapTIvate (capacitive touch EVM) uses the UART to communicate with the host GUI and for this reason we run in LPM0.

  • Hi Steve,

    I haven’t heard from you for a couple of days now, so I’m assuming you were able to resolve your issue.
    If this isn’t the case, please click the "This did NOT resolve my issue" button and reply to this thread with more information.
    If this thread locks, please click the "Ask a related question" button and in the new thread describe the current status of your issue and any additional details you may have to assist us in helping to solve your issues.

  • Dennis....

    My apologies...Been busy at this end....I am running the baud rate at 19200...My clock is supposed to be running at 16mhz....would you agree that these settings are correct?  and number 2 do you believe I should be able to run and wake up to rcv characters while in LPM3?  certainly seems so based on what you said above....

    Once again thanks and I'm sorry for the late response....

    void initClockTo16MHz(void)
    {
    //if defined (__MSP430FR2355__)
        FRCTL0 = FRCTLPW | NWAITS_1;
        do
        {
            CSCTL7 &= ~(XT1OFFG | DCOFFG);           // Clear XT1 and DCO fault flag
            SFRIFG1 &= ~OFIFG;
        } while (SFRIFG1 & OFIFG);                   // Test oscillator fault flag
    
        __bis_SR_register(SCG0);                     // disable FLL
        CSCTL3 |= SELREF__XT1CLK;                    // Set XT1 as FLL reference source
        CSCTL0 = 0;
        CSCTL1 &= ~(DCORSEL_7);
        CSCTL1 |= DCORSEL_5;// DCOFTRIM=5, DCO Range = 16MHz
        CSCTL2 = FLLD_0 + 487;                       // DCOCLKDIV = 16MHz
        __delay_cycles(3);
        __bic_SR_register(SCG0);                     // enable FLL
    //    Software_Trim();
        P6OUT &= ~BIT6;
        while(CSCTL7 & (FLLUNLOCK0 | FLLUNLOCK1));
        CSCTL4 = SELMS__DCOCLKDIV | SELA__XT1CLK;   // set XT1 (~32768Hz) as ACLK source, ACLK = 32768Hz
    //#else
    //#error "Failed to match a default include file"0
    //#endif
    }

    ps....my understanding is the Software Trim piece of code is NOT necessary and only allows syncing up to the clock faster....is that correct?

    Steve

  • Hi Steve,

    Yes, your clock is fine and you are correct about the software trim code.

    In regards to waking up from LPM3 to capture the first byte in the UART, from experience that doesn't work.  As a matter of fact, when we developed our MSP430 CapTIvate EVM, we ran into the same behavior.  That's why all the example code that uses the UART uses LPM0.

    I'll see if I can dig up the documentation that supports this and post it.

  • Dennis...

    Great I would love to see it....I found that running a 16MHz SMCLK and a baud rate of 19200 allows enough slop on the start up from LPM3 with the start up bit that I am successful at capturing UART rcv data....

    Steve

  • Hi Steve,

    To help illustrate what is happening when the leading edge of the start bit wakes the MSP from LPM3 and demonstrate how the delay in the DCO startup can cause an error in the UART, I put together an illustration using diagram 22.11 from the family user's guide.

    I think you figured it out in that increasing the BRCLK (bit rate clock) using oversampling improves the module's accuracy to sync up with the leading start bit. 

  • Thanks Dennis....

    I believe that resolves at least one of my issues...

    Steve

**Attention** This is a public forum