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.

  • Resolved

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

Intellectual 445 points

Replies: 15

Views: 590

Part Number: MSP430F6721

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

Where there is a will,there is a way.

  • Hi Zhiyong

    What's the clock source of the msp430f6721? How do you configured the UART?
  • In reply to Gary Gao:

    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,

    Where there is a will,there is a way.

  • In reply to Zhiyong Li (FT):

    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
  • In reply to Gary Gao:

    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.

    Where there is a will,there is a way.

  • In reply to Zhiyong Li (FT):

    Hi Zhiyong

    Why did use the REF as the DCO source? Why not the XT1?
  • In reply to Gary Gao:

    Totally missed this part. Will update it. But still, why we are having problem with Arm M0 only puzzles me.

    Where there is a will,there is a way.

  • In reply to Zhiyong Li (FT):

    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.
  • In reply to Gary Gao:

    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.

    Where there is a will,there is a way.

  • In reply to Zhiyong Li (FT):

    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.
  • In reply to Gary Gao:

    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.

    Where there is a will,there is a way.

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.