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.

  • TI Thinks Resolved

Launchpad - Software UART issue

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!

     

    Regards,

    Dung

  • In reply to Dung Dang:

    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.

    Regards

    Justin

  • In reply to Justin Smith52690:

    Justin Smith
    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.

    _____________________________________

    Time to say goodbye - I don't have the time anymore to read and answer forum posts. See my bio for details.

    Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.
    I'm sorry that  I can no longer provide help  in the forum or by private conversation.

  • In reply to Jens-Michael Gross:

    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.

  • In reply to eltury:

    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?

    Regards,

    Dung

  • In reply to Dung Dang:

    I'll check it out today and report back.

  • In reply to eltury:

    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)
    (received)
    56000
    ERROR

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

  • In reply to eltury:

    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.

     

    _____________________________________

    Time to say goodbye - I don't have the time anymore to read and answer forum posts. See my bio for details.

    Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.
    I'm sorry that  I can no longer provide help  in the forum or by private conversation.

  • In reply to Jens-Michael Gross:

    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

     

  • In reply to Harri Haataja:

    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.

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.