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.

Launchpad - Software UART issue

Other Parts Discussed in Thread: TUSB3410

My Launchpad development board arrived today and either I am in the wrong forum or I get to be one of the first to pose a question.

The preloaded demo application (temperature sensor) appears at first to be running correctly (i.e. the LED's blink on startup and change color according to temperature) but when I run the example GUI on my PC (XP Pro fully patched) I select the appropriate serial port then I get nothing. Running Hyperteminal (2400,N,8,1) also does not indicate any output is being received.

I downloaded IAR Embedded Workbench and successfully built the example code and debugged on the development board, and stepped through the Transmit() function. A good learning exercise but everything looked fine. I therefore suspect an issue with the internal chip timing, a problem with the serial/USB interface on the development board or a setup/compatibility issue with my PC. All tricky issues to diagnose on my first day playing with a new micro.

So my question are these a) has anyone else encountered this issue b) has anyone solved it?

  • Justin Smith,

    I have not seen this issue with the HW & code before. A few checks that you can do:

    1. Make sure the USB-UART driver is installed properly in windows. Device should show up under device manager.

    2. All jumpers should be populated, especially in this case the TX & RX jumpers. Technically only TX is needed, but all should be populated when it is delivered.

    3. If you have access to a scope, try to monitor the TX line to see if there's any activity. The temp data is transmitted based on the interval, or you can press the button to force send a character. If data shows up correctly, the problem occurs within the emulator circuitry or more likely the USB driver installation.

    Hope that helps, let us know if you get it working!




  • Hi Dung,

    I have had the opportunity to install the drivers on another computer (this time running Vista) with the same result. In response to the checks you suggested:

    1. Both the XP and the Vista boxes appear to have correctly installed the drivers. On both computers the board shows up in Device Manager as COM3.

    2. All jumpers are correctly installed. I removed all jumpers and the micro from the board and reseated them to ensure the connections were good.

    3. Unfortunately I do not have access to a scope but testing with a multimeter reveals a "not zero" voltage on the TX pin which I take to mean that at regular intervals the output goes high (i.e. data is transmitted).

    This I guess leads to the conclusion that there is an problem with the emulator circuitry. At $4.30 the obvious next step is simply to order another board.



  • Justin Smith said:
    testing with a multimeter reveals a "not zero" voltage on the TX pin which I take to mean that at regular intervals the output goes high (i.e. data is transmitted).

    The normal line level of a TTL Uart line is high. The transmission starts with a high-to-low-transition of the T Xline (start bit) and always ends with a high level (stopbit, idle line).

    You can test with a diode from VCC to RX (with a resistor, of course). It will flicker (at 1200Bd it should be visible even for single characters) with each start bit and transmitted 0-bit. Or you apply a speaker to the line :)

    If you want to use your multimeter, test against VCC and not GND. Id should show some mV (the port pin voltage drop) and increase by some depending on the traffic.

    Two other pssible problems: is the board powered at all? I take it since you're reading non-zero on the TX line. Then did you disable the hardware handshake in the terminal program (that is, if you're using hyperterm or such). If not, it might be just the terminal program refusing to send or receive due to a wrong RTS/CTS state.

  • Just fired mine up and all seems to be working except no activity on the screen of my terminal program. Scope trace reveals a transmission every 560 milliseconds or so at the TXD pin of the 20 pin DIP. Level is correct. 

    Hardware manager says the port on the PC is functioning correctly. There is activity at the USB connector but this is hard to interpret. 

    When I tried the sample GUI it seemed to hang and clicking on a port selection did nothing.


    Actually it's the 14 pin DIP that came installed.

  • eltury,

    with the scope shot were you able to translate the 8bits back into hex value? The pre-loaded code samples temp sensor and converts value to fahrenheit, so values should be in the 50~80 range assuming you're in room temp.

    Reversely, when you try to send a character from your terminal program, can you detect any signal on the RXD line with the scope?



  • I'll check it out today and report back.

  • This is PIN1.1(TXD) at room temp.

    No activity on RXD when I send something from the terminal program, BUT something on the board

    sends back an error.:


    XYZ Corporation (sent)

    I hope this will help someone at TI to analyze what's going on.

  • Hmmm, your scope shot makes no sense to me.

    1) the idle line level is high, yet your scope shows it low. Start bit is the first FALLING edge
    2) the line voltage should be 0..VCC, yet the high levels on your scope are 0.36V (seems to be 10:1 error)
    3) this last small high pulse shouln'd happen at all.

    My guess is that you have maybe a pulldown on the digital lines. The first high-block is just the idle line when activating the UART. Then comes a (low) start bit, then 11010010 (LSB first, 0x4b = 'K') and a shortened stopbit (high) which is cut-off by deactivating the UART and the pulldown takes control again.


  • Just to comment:


    1) TTL serial is normally positive contract (idle low, 0=0) while RS232 is negative contract (idle high). I don't know if this is inverted on the launchpad but it seems an odd thing to do.

    2) 10:1 is common for a probe, so it might just be a wrong setting


  • 10:1 probe is correct. This signal is from an out of the box launchpad.

    Also, I finally fired up my second device which appeared on COM39. It is working.

    The original one appeared on COM3 and it is the one that isn't communicating. 

    Any thoughts?

    I'll be looking at the TXD signal on the working unit.

  • The signal on the COM39 board is identical to the COM3 board, including the "narrow" end pulse.

    Obviously a port issue. Windows says port is functioning properly. Device shows up in Hardware Mgr. correctly.


  • Use the device mgr. to move the port around, but still no communication.

    Convinced it's a bad Launchpad.  

  • Well, the signal might look the same but might be a tad different in timing (factory tolerances). And this difference might be the difference between yes and no, or better 'good' and 'framing error' Or maybe the framing error is just not caught on the receiver side, or whatever. At least this is NOT what one should read on a normal serial line. What firmware is running on the device? I don't trust the TI example code - it is often too minimalistic and works only on the device it was written for (and sometimes only on this particular piece of silicon).

  • Both units are running the TI code that came programmed in the chips.

    One unit works and one doesn't. 

    The scope is looking at the 430 pin, not the final serial line.

  • It is very likely a flaky TUSB3410 on the non-working unit.

    Input data and clock to this chip are identical for both units. The outputs, however, are not.

  • eltury,

    your described behavior also makes me think the first launchpad has some faulty component(s) in the emulator circuitry. Final test could be wiring the TX/RX lines from the 1st launchpad to the 2nd one to use its emulator+back-channel UART, which (I'm almost certain) will work, but only further proves the 1st board being faulty.

    The extra narrow pulse at the end of the TX transmission is due to the tiny glitch in SW which does not turn off the peripheral function of the TXD pin immediately after transmission. This will be addressed in the next release of the example code. Attached please find the quick code fix.





  • Thanks for the reply. 

    I don't think I'll try that experiment, since I've spent more time on this then I should have. Glad I could help out somewhat.

    I'll try the new code. 

    Returning this product for a new one would be more costly than simply ordering another if I need it. I guess paying $8.60 for one is still a good deal.

  • eltury,

    thanks for doing the experiments. Your feedback is definitely useful to us, especially to determine & maintain the quality @ production for our future batches.


    let us know if the 2nd LaunchPad kit gives you better luck!




  • eltury said:
    The scope is looking at the 430 pin, not the final serial line.

    That's what I thought. And it is wrong. That's not your fault. it's the original code then, which does it wrong.

    Having a long low line on the MSP pin is a break condition. Depending on the MSPs UART mode it can cause an interrupt or other things. And on the PC side it might cause some actions too.
    Also, the shortened stopbit is an error condition. Depending on the MSP configuration it will cause a framing error interrupt and the byte is or is not received. On the PC side, also anything can happen.

    And if the clock timing of the two devices is different, the faulty handling of the lines may cause an error on one and no error on the other system even if not physically defect.

    There was a different thread in this forum about UART and framing and parity errors, which copuld be tracked back to slighly different timings of two PC serial cards, while both cards seemed to be okay with each other and other PCs.

    A difference of 5% (including both sides' timing errors) is enough to make the connection fail, even if everything else is okay (and it isn't with the original launchpad software)

    Is the source available somewhere? (without buying one, I mean)

  • The source code and schematic are available at the Launchpad wiki.

    The corrected source (as provided in a post above) causes the final errant pulse to disappear as well as keep the line high. 

    I reprogrammed both of my boards. The original good one still works and the bad one still doesn't send values. Which, again, points to a faulty USB chip.


  • Jens,

    the code project on the wikipage has not been updated and still contains the error. We're in the process of updating the wiki page with the new code project & the user's guide. Until then, please simply use the code attached to the previous post.



  • eltury said:
    The corrected source (as provided in a post above) causes the final errant pulse to disappear as well as keep the line high. 

    So one bug foudn and fixed while looking after a completely unrelated one.

    That's efficient :)

  • Thanks to everyone who helped out on this question.

    I have been away for the past week and was pleasantly surprised by the amount and quality of answers this question had generated. As expected even with the updated code I am still unable to get my board working. The new board has been ordered but unfortunately it is on back order until August. When I get the new board I intend to try Dung's experiment wiring the two boards together directly since one of the applications I was investigating the kit for involves serial communications. I will post the results at that time.



  • Dung Dang said:

    ... The extra narrow pulse at the end of the TX transmission is due to the tiny glitch in SW which does not turn off the peripheral function of the TXD pin immediately after transmission. This will be addressed in the next release of the example code. Attached please find the quick code fix. ...

    I think that quick code fix is incorrect. (I am still waiting for my LaunchPad. Thus I cannot try it.)

    The real problem is that when BIT1 of P1SEL is 0, the TXD pin follows BIT1 of P1OUT and BIT1 of P1OUT is unpredictable after BOR. Thus I think you need to do "P1OUT |= TXD;" during initialization.

  • Solved!

    My second Launchpad development board arrived and I plugged it into my PC with the same result; so I went looking a bit further at the configuration of both my PC (Acer - Vista) and my laptop (Dell - XP Pro).

    It turns out that both these seemingly quite different computers have one thing in common - both have a Conexant modem attached to COM3. This did not occur to me before because the modem does not show up in the ports list in Device Manager and when connected the Launchpad correctly shows up as COM3, and indicates that there are no hardware conflicts. However when you open a terminal program or the example GUI it seems that the Conexant driver gets in first; this can be confirmed with the terminal program by sending an AT command.

    The solution is simple, go to the Phone and Modem Options under the Control Panel. Select the Modems tag and find the modem attached to COM3. Select Properties and then the Advanced tab and click on the Advanced Port Settings button (to enable the button on Vista you need to first click the Change Settings button on the General tab). Change the port number to something other than COM3 and accept all the changes. Reboot.

    Both the original board and the new board are now working as expected. Thanks all for your attempts to help me with this issue. Unfortunately in this case I think the problem can be classified as user error; I hope this thread can assist others who are having the same problem.

  • I have a launchpad with a captouch booster board. I see the same UART issue where idle is low and a strange pulse in the stop bit. Is there an updated uart driver for the captouch?

**Attention** This is a public forum