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.

MSP430 SPI interface with MAX3111E on UART for RF link

Other Parts Discussed in Thread: MSP430FG4619

Hi all,
This is the setup

The MSP430(System controller) is the master and communicates on SPI with UART on MAX3111E .
 MSP430 is the master and I am using 3 wire mode with CS to control SPI commn.
The flow of the communication is like this

CS low
Write to MAX3111E configuration register (16 bit) - to set the baud rate etc
CS high

CS low
Read the configuration register to see if the configuration is done properly
CS hi

But I am not able to configure the  MAX3111E properly. The configuration is not happening properly (I am writing #CC 0Ch but reading #40 40h).

I think communication is not getting setup properly.

I wanted to confirm two things
1) Do I have to setup the baud rate of UART as per the SPI SCLK(using SMCLK-32768*32 Hz.

2)  Also, after sending the command for read configuration register do I have to send dummy bytes to receive data.

3) Do I have to monitor UCBUSY to see if any activity is happening on SPI before deasserting CS. Currently I am using UCA0TXIFG and UCA0RXIFG .

I am attaching the code and also 1882.MAX3110E-MAX3111E(RF LINK).pdfthe datasheet of MAX3111E.

Thanks........

 

  • Any particular reason why you don't just use a UART in the MSP430...?

     

  • Hi Andrei,

    Thanks for your reply....

    The board I am working on is hardwired in this way-
    P7.1 - MOSI
    P7.2 -  SOMI
    P7.3 - SPICLK
    From previous documentation of the hardware, I found that this interfce is on SPI. Also the MAX3111E's UART only has an SPI interface for Microcontrollers.

    After receiving your reply, I checked the datasheet of MSP430FG4619 and P7.3 for SPISCLK has the following desription

    "General-purpose digital I/O / external clock input -- USCI_A0/UART or SPI mode, clock output -- USCI_A0/SPI mode / LCD segment 30 "

    Does this mean that I can use the port as UART for this interface with MAX3111E by configuring P7 accordingly?

  • sunil sharma said:
    Does this mean that I can use the port as UART

    Yes, you could use the port as a UART - hence the question, why add an external UART?!

    sunil sharma said:
    for this interface with MAX3111E

    No - as already noted, the MAX311x has an SPI interface to the controller.

    But my question was: why add an external UART, when the microcontroller already has a UART built in? Isn't that just a waste of an external chip?!

    Do I take it that this is not your own board design...?

  • Andy Neil said:

    Yes, you could use the port as a UART - hence the question, why add an external UART?!

    - The board is already designed and I am just trying to prove the interfaces as part of my project.  
    What I can think of the reasons for using MAX3111E are -
    a)  The same port pins are multiplexed for SPI communication with the RTC and DSPs.  So thats why I think the it was thought to use an external UART.
    b) Also, most of the other ports are in use for some purpose, 

    As per the datasheet hardware UART is available on port 2,4 and 7 . But at all these places some device is interfaced. Port 4 has a RS 232 interface which is planned to be used for a digital compass or for debugging.

    So , as of now I will have to get the SPI interface going as the RF link will be used via this chip's RS232 transceivers.

    Any help in this regard will be very useful. Any alternate suggestion is also welcome, but mostly I will have to work as per the board available to me.

    Thanks a lot for your interest and time.

    Regards

    Sunil

  • You're right, if the SPI bus is shared with other peripherals, then indeed you cannot use teh hardware UART for the RF interface. It's an either-or and UART is limited to exactly one peer (unless you implement an RS485 interface or similar)

    So to answer the original questions:

    sunil sharma said:
    1) Do I have to setup the baud rate of UART as per the SPI SCLK(using SMCLK-32768*32 Hz.

    Generally, the SPI baudrate is unimportant. On SPI, the master dictates teh baudrate and the slave obeys it. So baudrate for SPI can go from 0Hz to whatever the slave and master support.

    The UART baudrate of the slave is independent. Of  course, if you need to read a slave register to get the received data, then the SPI baudrate needs to be high enough to send the register read request and transfer the data in the same time data is comming in. So SPi baudrate must be by a factor (depends on teh protocol) higher than UART baudrate. But it can be much higher than required without problems.
    Keep in mind that SPI baudrate is not applied all the time to the clock line. There are onnly as many clock pulses as bits are shifted in and out. 8 per byte. If nothing is transferred, no clock pulses are generated.
    So you'll need to set the slaves UART baudrate by some config register or such. And maybe the slave requires an independent, always active clock source for its baudrate generation.

    sunil sharma said:
    2)  Also, after sending the command for read configuration register do I have to send dummy bytes to receive data.

    Yes. The master doesn't know how many bytes you want to receive. And since the master generates the clock pulses as required, to shift data in, you need to tell it htat itneeds to do so. It is done by sending a dummy byte. One byte out, one byte in. give and take. That's how SPI works.

    sunil sharma said:
    3) Do I have to monitor UCBUSY to see if any activity is happening on SPI before deasserting CS. Currently I am using UCA0TXIFG and UCA0RXIFG .

    It depends. If you're receiving, you can usually de-assert CS once you received the last byte. At this moment, the last byte in TX buffer has been sent too. When sending, you can also just check whether the last byte you sent has resulted in a byte received.

    However, some slaves are a bi tpickery and don't like CS going high before the last clock cycles was completed (even if you already received the last byte and the last bit was already sent). So checking UCBUSY is the safest way.
    Unfortunately, there have been reports that in some constellations with UCKPL/UCKPH the UCBUSY flag goes low too soon, requiring an additional delay. IIRC, it was a very pickery slave. :)

**Attention** This is a public forum