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.

MSP430F6721: What could go wrong when interfacing with Arm M0 MCUs via UART?

Part Number: MSP430F6721
Other Parts Discussed in Thread: MSP430FR2532,

Hi,

We have two systems (A & B) that communicate with each other via UART. System A is built around MSP430F6721, system B is built around either MSP430FR2532 or Arm M0+ MCUs from NXP/STM32. MSP430FR2532 based system B works perfectly fine with system A. However, Arm M0 based System B somehow doesn't work well. After varying amount of time, from days to weeks, some System B will seem to become non-responsive. Power cycle system B doesn't make it responsive again. But power cycle System A does the trick. RXD, TXD, RTS and CTS pins are all used to interface system A & B.

What could go wrong in such setup? As a temporal solution, we could reset system A if system B becomes non-responsive, hopefully that will work. but it is still nice to know the underline causes.

Edit: by non-responsive, I mean System A doesn't receive response from B after sending request to it while other parts of A like other UART, LCD all work just fine. Since power cycle B doesn't solve the problem while power cycle A does, I assume A either cannot send or receive communication from B. 

Thanks in advance.

Zhiyong

  • Hi Zhiyong

    What's the clock source of the msp430f6721? How do you configured the UART?
  • Hi Gary,

    Thanks for your reply. The clock is sourced from watch crystal as reference:

    	//Turn on XT1 watch crystal, wait til XT1 stablize
    	UCSCTL6 &= ~(XT1OFF);                  							// XT1 On
    	UCSCTL6 |= XCAP_3;                     							// Internal load cap
    	UCSCTL3 |= SELREF__REFOCLK;             						// Set DCO FLL reference = REFO
    	UCSCTL4 = SELA__XT1CLK | SELS__DCOCLKDIV | SELM__DCOCLK;      	// Set ACLK = XT1, SMCLK = DCOCLKDIV, MCLK = DCOCLK
    	__bis_SR_register(SCG0);               							// Disable the FLL control loop
    	UCSCTL0 = 0x0000;                      							// Set lowest possible DCOx, MODx
    	UCSCTL1 = DCORSEL_5;                   							// Select DCO range 16MHz operation
    	UCSCTL2 = FLLD_2 | 121;                							// fDCOCLK = 4 * (121 + 1) * 32768 = 15,990,784Hz, fSMCLK = 4MHz
    	__bic_SR_register(SCG0);               							// Enable the FLL control loop
    	do {
    		UCSCTL7 &= ~(XT2OFFG | XT1LFOFFG | DCOFFG);					// Clear XT2,XT1,DCO fault flags
    	    SFRIFG1 &= ~OFIFG;                 							// Clear fault flags
    	} while (SFRIFG1 & OFIFG);  

    The following is code to initialize UART:

    	P1SEL |= BIT2 | BIT3;                   // Set P1.2, P1.3 to non-IO
    	P1DIR |= BIT2 | BIT3;                   // Enable UCA0RXD, UCA0TXD
    	UCA0CTLW0 |= UCSWRST;                   // **Put state machine in reset**
    	UCA0CTLW0 |= UCSSEL_1;                  // CLK = ACLK
    	UCA0BRW_L = 0x03;                       // 32kHz/9600=3.41 (see User's Guide)
    	UCA0BRW_H = 0x00;                       //
    	UCA0MCTLW = 0x5300;                     // Modulation UCBRSx=0x53, UCBRFx=0
    	UCA0CTLW0 &= ~UCSWRST;                  // **Initialize USCI state machine**
    	UCA0IE |= UCRXIE;                    	

    Thanks again,

  • Hi Zhiyong

    For the XT1 you can check your Layout refer to this documents www.ti.com/.../slaa322d.pdf
    For the software you can refer to this demo code
    dev.ti.com/.../node

    Best regards
    Gary
  • Hi Gary,

    I don't think layout of XT1 is the problem, because hundreds of System A work just fine over the course of more than two year when interfacing with another MSP430. The problem only comes when we need to interface with Arm M0 based system.

    Thanks.
  • Hi Zhiyong

    Why did use the REF as the DCO source? Why not the XT1?
  • Totally missed this part. Will update it. But still, why we are having problem with Arm M0 only puzzles me.
  • To be honest I have not saw this kinds problem. What I recommend is that use the demo codes that I sent you and test is with the Arm M0 device. The only thing that you should make change of the demo code is that make the ACLK source to XT1 to make sure the MCLK and the UART the same clock source.
  • What are the consequence of MCLK and UART use different clock sources? We have another issue with System A, not sure if it is related.
  • Hi Zhiyong

    I am not sure about the result of MCLK and UART use different clock sources. What I do is just to reduce the risk.
    For the errata related to UART just USCI42 www.ti.com/.../slaz339ad.pdf But that seems not related with your problem.
  • Any more detailed description about USCI37? System A does have an I2C EEPROM. UARTRXBUF is read by ISR, so it is very likely it will be read when I2C is active at some point. Not sure if this is related, but it definitely warrants some investigation.
  • Hi Zhiyong

    That means if the previous data was not read from the receive buffer UCBxRXBUF at the end of a reception, the bus is stalled by holding SCL low. As soon as UCBxRXBUF is read, the new data is transferred into UCBxRXBUF, an acknowledge is sent to the master, and the next data can be received. So read the UCBxRXBUF as soon as possible when a data is received.(Or make the I2C clock slower to give more time for CPU to read the data)
  • Could be  a RTS and CTS  deadlock . 

  • Hi Peter,

    Could you elaborate this a little more? I assume such deadlock involves both A & B, therefore power cycle B or disconnect/reconnect B to A would break such deadlock. 

  • This deadlock is when both sides are in the DO NOT SEND DATA state.

    A logic analyzer like Salae is helpful here

  • Pulled one System A that is acting this from field. UART TX works just fine, but MSP430 doesn't respond to input from B on RX line. After a watchdog caused reset, System A starts to work fine again.

    What could cause MSP430 to not process UART RX? RX interrupt is not set?

    Update: the problem is caused by a bug. In certain rare situation, UART RX on MSP430 can be disabled by code forever. The reason we only started to see the problem when interfacing with Arm M0 MCUs is the implementation is different from MSP430FR2532, therefore makes the bug easier to manifest itself. The problem has nothing to do with hardware difference of M0 in general from MSP430.

    Thanks every for participating the discussion.

**Attention** This is a public forum