Pololu USB AVR Programmer - USART problem

Support Other Pololu products
1

I’m having trouble using the Serial TTL function with the USB AVR Programmer. Could someone help me out?

System details: a Dell laptop running Windows 10 (migrated from Windows 7) with usbser.sys version 10.0.10586.71 (I’ve read the previous post on this forum about problems with Serial TTL on Windows 10 machines). I downloaded and installed the “USB AVR Programmer Windows Drivers and Software release 121114” from pololu.com/product/1300/resources before using the programmer.

Usage: I’m programming an ATmega168 using the AVR-GCC toolchain, AVRdude and Sublime Text 2 code editor, and have flashed the chip with a simple USART test which you can see here: github.com/hexagon5un/AVR-Progr … alLoopback.

Ports: The programmer is on COM4, and the Serial TTL port is on COM5. (The programmer works brilliantly by the way, and is much better than the USBasp that I used previously, much more reliable.)

Terminal: I’ve tried both Bray’s Terminal and PuTTY, both configured to use 9600 baud on COM5, and 8 bits, No parity, 1 stop bit (8N1).

Programmer/ TTL wiring: I’ve soldered a six-pin header into the contact holes for serial TTL/ Sloscope on the Pololu programmer. The flashed chip is on one breadboard, Pololu programmer in a separate breadboard. I have both the Pololu programmer wires and the TTL wires (VCC, GND, TX and RX) all connected to the appropriate pins on the Serial TTL header, ie TX header pin connects to the ATmega RX pin (pin 2) and vice versa. The AVR chip and programmer are running on the 5 volts from USB with no external power.

What happens: When I plug the programmer into a USB slot, the Pololu programmer gives me a yellow flashing light, so all looks good. Bray’s terminal gives me green indicators for CTS (Clear To Send), CD (Carrier Detect), DSR (Data Set Ready) and RI (Ring Indicator). I’ve also used a voltmeter to check continuity - I think there are good connections.

But I get no transmission from the chip. The code I’ve flashed the chip with should push a “Hello world” message via USART, then echo any text transmitted to the chip, but there’s nothing.

I’ve tried Adafruit’s FTDI Friend with the latest driver, and the same thing happens: no transmission. FTDI says it supports Windows 10, so surely this isn’t a Windows 10 problem. I must be doing something really, really daft, but I can’t see it! Help! :slight_smile:

2

Hello! Is anyone out there? :smiley:

3

Hello.

I am sorry you are having trouble getting the USB-to-TTL-Serial adapter feature to work on the Pololu USB AVR Programmer. It is not clear to me what might be causing the issue. Did the programmer ever work on Windows 10? Can you post pictures of your setup clearly showing your connections between the AVR chip you are trying to communicate with and the AVR programmer and the USB cable connecting the programmer to your computer? Can you do individual loop back tests with the chip and the AVR programmer to verify that their UARTs are working as expected?

- Amanda

4

Also try swapping the RX and TX connections. Sometimes there is confusion about these.

5

Hi Amanda and Jim

Thanks for your replies. It’s late in GMT and I’ve just got home from work, then will be off to bed! Hopefully I’ll get home earlier tomorrow, in which case I’ll take photos. I think the programmer and UART are wired correctly. The programmer works. I have UART connected as follows: VCC to the 5V feed on the breadboard, GND to ground on the breadboard, TX to RX on the chip (pin 2 on the ATmega168) and RX to TX on the chip (pin 3). All using solid core wire with good connections.

I took delivery of the programmer last week and was trying it for the first time over the weekend. The programmer (COM4 on my system) worked brilliantly out of the box. The Serial TTL has not worked at all so far. I can get the terminal software to recognise the connection. The chip code compiled and flashed without error. The chip is programmed to transmit text by UART. No text is received by the terminal. The chip is also programmed to receive text via UART, and echo it back: no echo.

I’ve tried swapping RX and TX. The best result I get is setting it as it should be, ie RX to TX and TX to RX. I’ve also tried a whole range of baud rates, although I have it set at 9600 in the make file. The terminal is set for 8N1.

I haven’t been messing with fuses on the chip, but have messed with clock speed, particularly in the make file. I’ve ordered a couple of new chips just in case I have a bad internal clock on the one I’ve been using. (I’m not using an external source.) I’ve also had trouble with a FDTI Friend and a Serial-TTL cable, so I’m increasingly starting to suspect the chip.

6

Here is a picture of the connections.
drive.google.com/file/d/0B1j_ll … sp=sharing

7

Thanks for the picture. Your connections are all correct as you stated in your previous post. Did you try the loop back test that I had suggested in my last post?

- Amanda

8

Sorry Amanda, could you explain by a loopback test? You’re dealing with a muppet here!!

9

To do a loop back test, you would need to connect the device’s TX line to its RX line, then send characters to the device’s COM port using a terminal program (e.g. PuTTY) to see if the same data is echoed back.

- Amanda

10

Amanda, thanks for explaining. I’ve tried a loop back test and no data was returned. Does that indicate a fault with the unit, or could I be doing something wrong? I kept everything connected as in the photo, except that I inserted a jumper cable into the breadboard to connect RX and TX on the programmer. Then I used Bray’s Terminal to transmit a short word at 9600 baud 8N1 (no handshaking, no inversion). In Bray’s terminal right at the bottom of the window it keeps a count of Rx bytes and Tx bytes. It recorded the bytes going out but nothing coming in, and the text did not appear in the “Receive” box in the main part of the window, either.

David

11

Could you reply?

12

Sorry for the delay in getting back to you; I somehow missed your reply.

If no data was echoed back in the terminal program during the loop back test, it is a strong indication that the UART is not working properly on the device. However, it sounds like you kept the connections between your AVR chip and AVR programmer during the test. Can you try performing the loop back test again on the AVR programmer without it being connected to your AVR chip and post a picture of the test setup? Can you also post a screenshot of your Device Manager with “Ports (COM & LPT)” and “Pololu USB Devices” entries expanded as well as a screenshot of the Bray terminal?

- Amanda

13

Thanks Amanda. Sure, I’ll do that - hopefully some time tomorrow after Dad’s Taxi duties are completed!