• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 79 subscribers
  • Views 3254 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP 430F1611 USART communication with Hyperterminal

Dave Charles
Prodigy 140 points
Other Parts Discussed in Thread: MAX3232, CC2530, CC2430

Hi all,

I have MSP 430F 1611 and I want to enable USART communication between the device and a hyper terminal.  According to the slau049f f for MSP430x1xx pdf file, it is possible to do the same.  I am using a java program and putty as the program to receive the outputs from the device. Neither seems to be getting any outputs from the MSP. I have provide code snippets so that the forum members can highlight and possibly give an explanation of the area where I am faltering in the code. I also read through the slau049 - MSP 430x1xx pdf and have put values as per the explanation provided for the registers in the pdf document. 


First, I initialize the halInit() and also enable the interrupts.  Next, I have the code as shown below
    P3SEL |= 0x30; // P3.4,5 = USART0 TXD/RXD
    ME1 |= UTXE0 + URXE0; // Enable USART0 TXD/RXD
    UCTL0 |= CHAR; // 8-bit character
    UTCTL0 |= SSEL1 ; // UCLK = ACLK = 32.768kHz   --- (Tried SSEL0 )
    UBR00 = 0xD0;
    UBR10 = 0x00;
    UMCTL0 = 0x00 ;
     
    UCTL0 &= ~ SWRST; // Initialize USART state machine
    IE1 |= URXIE0 + UTXIE0; // Enable USART0 RX/TX interrupt  

Then I have a while loop sending a character to the terminal 

while (1)
    {
        toggleLed(1);       
        setLed(1);
        delayMs(1000);
        while (!(IFG1 & UTXIFG0)); // USART0 TX buffer ready?   
        TXBUF0 = 0x42;
    }
Is this code correct? In debug mode, the loop functions and I can see the led toggling. When downloaded and executing on the device through IAR, the led is not blinking. 
I removed the last two statement (while and Txbuf) and added a printf stmt and it loops through. Am I missing something in this USART code?
I am a newbie and any inputs and direction from the forum members is highly appreciated.
Cheers,
Dave
  • 0
    Genius 4170 points

    Hello,

    my first thought is:

    You try to communicate with a PC on serial line right? Your PC should work with differential signals, whereas your MSP430 works with single ended signals, so you should not be able to send from PC nor receive to your PC via this communication.

    I did never try it like you did though. The way I do it is a RS485 or RS232 serial connection, then, before the signal reaches the MSP430, i put a signal converter that converts to a single ended signal in the right voltage ranges ( 0...3V). And then at least you should be able to send and receive something with your PC to µC and vice versa.

    Next step would be to find some adequate protocol for communication, that has for example parity checking, etc.

    Hope this could help you.

  • 0 in reply to seb
    Prodigy 140 points

    Hello Seb,

    Thanks for the reply. I will briefly explain the set up and my understanding, I might be wrong in my approach and thinking. The putty program or the java program is using the serial COM port to listen to the incoming signals. You can check which port the MSP is connected through your operating system. And you can have any of the programs to listen to the port and output the information. The MSP book does not mention about RS232 or RS485. All you have to do is sync correctly on both sides for an effective communication, meaning they should be set for the correct baud rate, stop bits and flow control to make the communication possible. The present code on the MSP is set approximately for 9600 baud, no stop bits, no parity enable and character length of 8 bits and this is same on the other end i.e. the java program or putty. The clock signal used for the baud rate is done through the SSEL0 or 1.  Theoretically, this should function. I don't know if there is any other set up needed or this is not possible. 

    Cheers,

    Dave

  • 0 in reply to Dave Charles
    Guru 227245 points

    Dave Charles said:
    The MSP book does not mention about RS232 or RS485

    No. it talks about the protocol setup.
    However, the MSP is producing and accepting TTL level signals and the PCs COM ports (and the very most USB/serial converters) are producing RS232/V.24 signals.
    The physical connection between MSP and PC is not covered in the users guide.
    If you cut the cable, still the COM port will show up in the OS,a nd both, MSP and PC program are configured correctly, and it will nto work. Same if the electrical signals are wrong and incompatible.

    So if you're sure the software is right (because it is a demo code that is supposed to work), then the only possible reason for failure is the hardware. And using the wrong electrical connection is a common reason.

  • 0 in reply to Jens-Michael Gross
    Prodigy 140 points

    Jens, thank you for your reply.

    Yes, I agree that it talks about the protocol set up meaning (baud rate, stop bits....) and internally it could be using the RS 232 or RS 485 because it acts as a serial connection. The developer has to set the values correctly for the communication to work.

    The set up demo is on the same machine, meaning, the USB connection to the MSP and the java / putty program are on the same box. I am not using an external connection (serial cable) to talk to the other program. I am not so sure that this set up is possible. I come from the socket connection world and look at all of them as sockets. I dont know if a separate set up is necessary for it to function. The java program and the putty program settings are controllable.

    Jens-Michael Gross said:
    the only possible reason for failure is the hardware. And using the wrong electrical connection is a common reason.

    The box is new and there are no external connections so the possible problem, in all possible likelihood, is the code. The set up either on the receiving side or the transmitting side has a problem.

    I have a question - When you output printf statements how does it come on the putty console or the java console?

    Cheers,

    Dave

  • 0 in reply to Dave Charles
    Genius 4170 points

    Meassure the real physical Send and Receive signals that go rom and into your PC.

    If they are 0...3V everything should work, but I would guess they are differential signals or TTL form the PC, as long as you are really using the serial output from your PC with nothing attached to it like a converter etc.

    So I would suggest until changing software code, test your hardware, when everything is fine there test your code,

    because you cannot fix hardware with software :)

    That sounds smart.

  • 0 in reply to Dave Charles
    Guru 227245 points

    Dave Charles said:
    The set up demo is on the same machine, meaning, the USB connection to the MSP and the java / putty program are on the same box.

    Fine. And how is the serial port of thr MSP connected to the PC?
    The 1611 does not have an USB controller. So what do you mean with USB connection to the MSP? The FET? It provides no serial channel from MSP to PC. Only JTAG (even though the IAR debugger 'fakes' a console connection by using debugging tricks, but this is unavailable outside the debugger)
    Is it an USB->serial converter? If so, the converters usually emit +-3 to +-12V RS232 signals that are not compatible with the MSP (which requires 0V/VCC TTL signals)

  • 0 in reply to Jens-Michael Gross
    Prodigy 140 points

    Hi Jens-Michael and Seb,

    Thanks for your response. I have much better idea and understanding after the explanation from both. 

    Jens-Michael Gross said:
    Is it an USB->serial converter? If so, the converters usually emit +-3 to +-12V RS232 signals that are not compatible with the MSP (which requires 0V/VCC TTL signals)

    So then, how to interface the computer with the MSP. My requirement for this demo is to send some values to the MSP430 (CC 2530 ZNP kit to be precise). This will in turn process the information and do some further activities and transmit it wirelessly to other devices.

    If there is no possibility of communicating with the MSP from the laptop and assume for this demo that I have the device connected to the USB, will I be able to communicate to the device as Jens-Michael has mentioned through the

    Jens-Michael Gross said:
    IAR debugger 'fakes' a console connection by using debugging tricks,
     

    I came across a EZ430 Chat (http://processors.wiki.ti.com/index.php/EZ430_Chat) which uses the EZ 430 backchannel UART configuration (http://processors.wiki.ti.com/index.php/EZ430_Backchannel_UART_Configuration). I dont know if it is applicable to my kit. A set up similar, as shown, is my requirement where I communicate from the laptop to the MSP device and back. I don't need the back communication (from device to laptop) but a forward communication to the device from the laptop is essential.

    Is this possible? If not what alternatives do I have?

    Cheers,

    Dave

  • 0 in reply to Dave Charles
    Guru 227245 points

    Teh 'fake console' works by placing a debugger breakpoint into the printf function, fetchign the value that shall be 'sent' by JTAG right form teh processor register. The code itself jsut discards the dat aand doesn't notice that the debugger pas peeping.

    TZhe LaunchPad backchannel UART is a different thing. It (ab)uses two unused I/O pins of teh TUSB chip that connects the PC to the FET (1612) chip on the LaunchPad, to simulate a second serial connection. This is only available on the LaunchPad and the EZ430-RF2500. No other EZ430 hardware has this feature. But many have a separate RS232 connector with appropriate hardware.

    So how to connect the MSP?

    The 1611 has an USART module that offers UART (serial port) funcitonality. The output pins RX and TX need to be conencted to an RS232 transceiver such as the MAX3232 and can then be routed to a PCs COM port.
    Baudates of 115200Bd are no problem, if the MSP has a stable clock supply (e.g. an 8MHz crystal)

    It's up to you to write a transfer function that manages the serial transfer. Including printf generates the bytes to be sent, but does not actually send them (you'll have to provide a proper putchar function that does the actual transfer)

  • 0 in reply to Jens-Michael Gross
    Prodigy 140 points

    Hi Jens-Michael,

    Thanks for clearing my doubts.

    I have a question to wrap-up this thread. Let say if I have a LaunchPad, is it possible to use the LaunchPad's UART to serially communicate with the CC2530 ZNP kit on UART to transfer the information from the laptop. In effect, I am using the LaunchPad as a bridge between the laptop and the CC2530 ZNP. The launchpad communicates to the laptop via the USB (provided in the kit) and the information retrieved by the launchpad from the laptop uses the UART to transfer the information to the CC2530 ZNP kit. This is a stop-gap arrangement to tide over the issue as it would be difficult to add additional requirements and development at this stage.

    Any inputs would be highly appreciated.

    Once again thanks for a clear explanation.

    Dave

  • 0 in reply to Dave Charles
    Guru 227245 points

    The USB connection on the LaunchPad is an USB/serial converter. And the connection between the LaunchPad MSP and the PC is a serial one, only tunneled through USB.
    Also, the pins on the MSPs with hardware UART are the same as required for the software timer uart.
    So even though the connection between MSP and PC is limited to 9600Bd, you can use the hardware UART in the bigger G chips only for the PC connection OR the CC2530 connection (and no PC conenciton at all).

    Since the biggest G series MSPs have two timers, it might be possible to connec tthe PC using the hardware UART and the CC2530 using a software UART on the second timer. However, a software UART is slow, and you're too limited to a low baudrate.
    Worse, the G-series MSPs do not allow for a high frequency crystal that you could use as timebase for higher baudrates. So you're limited to 9600Bd or (for stability, much) less.

    Well, the CC2530 is programmable too. So you might stay from a serial connection between MSP and CC2530 and implement a parallel connection. (e.g. 8 data bits and three control bits, read, write and select). It would relax timing compared to a software UART.

    However, if the CC2530 is programmed using serial UART, why not using a simple USB->serial converter with TTL outputs and directly communicate with the CC2430?

**Attention** This is a public forum