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: 603

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.

  • In reply to Zhiyong Li (FT):

    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 . 

  • In reply to Peter Dvorak:

    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. 

    Where there is a will,there is a way.

  • In reply to Zhiyong Li (FT):

    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.

    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.