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.
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?
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!
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Dung Dang:
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.
In reply to Justin Smith52690:
Justin Smithtesting 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:
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)(received)56000ERROR
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 edge2) 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
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.
I'll be looking at the TXD signal on the working unit.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.