Running on 64-bit Fedora 7 (linux) -- Did I Fry It?

[BobCochran]

I think I fried my usbtinyisp. My problem was: using the x86_64 bit, Fedora 7 (official release) binary packing of avrdude, it couldn't find the programmer. I'd connect the USB cable, get the green led, and run avrdude and still I would get an error message that it could not find the device.

I noticed the udev rule suggested for Linux, and added that. Still couldn't find the programmer.

I whipped out my Windows XP laptop, booted XP, installed the version 1,10 driver, and after a little fiddling with wires, the avrdude that comes bundled with WinAVR (20071221 release) found the programmer, and spoke to the Atmega644 part I had breadboarded, too! So this seemed good news. I stopped for the night and went to bed.

Tonight I fired up my Linux machine and downloaded the source code for avrdude-5.5 (as the source rpm package that the Fedora people provide. This includes a patch for 64 bit systems.)

I removed the // (comment) text from the if defined(HAVE_USB) line in usbtiny.c because I thought comments in the same line as an ifdef were not a good idea.

I compiled it using gcc, without applying the 64-bit patch that came with source rpm file. I also used a --prefix=`pwd` --sysconfdir=`pwd` string to allow me to later run the avrdude executable from the directory I was putting the object files in. When I say I compiled it I mean I ran `./configure` and `make` to verify everything compiled cleanly. I did nt run `make install` since I didn't think I need it. (However I am very, very, very green with c programming and could be wrong.)

Then I connected the USB cable to the usbtiny device. The usbtiny was connected to the Atmega644 through a Sparkfun breakout board I had added connectors to and then plugged into the breadboard where the 644 was installed. However, the AtMega644 circuit itself was not powered on. If I don't have it powered on, then avrdude should find the programmer first (which is getting power over USB) and then complain that it couldn't find the target chip.

Then I ran ./avrdude -c usbtiny -p m644

and still the device was not being recognized.

Then I remembered a little late that I can't get output as an ordinary user if I ran 'lsusb', but I could if I was root. The significance of this finally dawned on me. I su-ed to root, and then ran avrdude again.

It looks like avrdude finally found the part, but at that point it issued an error message and the red LED on the programmer switched on. I was surprised by this and didn't pay much attention to the text of the error message. I think (but cannot prove it because I didn't think to write down the text of the error) that it was issued by the usb_tiny_recieve() function in usbtiny.c. I think also that I saw the values -4 and -1 in that order, or perhaps it was -1 and -4.

Here is a snippet from the usb_tiny_receive code that I think issued the error message:

if (nbytes != buflen) {
fprintf(stderr, "%s: error: usbtiny_receive: %s (expected %d, got %d)\n",
progname, usb_strerror(), buflen, nbytes);
exit(1);


To get the red LED on the usbtiny device to turn off, I unplugged the usb cable from it. Then I replugged the cable in there, expecting to see the green LED come on. But now the green LED won't come on! And `lsusb` no longer sees the device. My /var/log/messages no longer registers a low-speed usb device when I plug the cable in, either.

So I wonder if I have released the magic smoke from my device and killed it dead? And maybe taken the ATMega644 with it? Maybe I should have kept this simple and ran the official Fedora distributed version of avrdude as root?

[BobCochran]

Following the above, I tried the usbtiny programmer on Windows XP and it turns out it at least initializes the target device normally on that platform. Here is the sequence of my actions:

1. I booted to XP and logged into my user account (which has administrative privileges...)
2. I plugged the usbtinyisp programmer into an powered USB hub. The programmer in turn is connected to an AtMega644 circuit on a breadboard. The breadboard circuit isn't powered on yet.
3. The green LED goes on to my great pleasure!
4. In a command prompt I issued

`avrdude -c usbtiny -p m644'

5. avrdude is able to talk to the programmer, but not the Mega644 since that circuit isn't powered on.
6. I connect power to the ATMega644 circuit.
7. issuing

`avrdude -c usbtiny -p m644'

now results in avrdude saying it can't find the usbtiny device.

8. I disconnect the usb cable from the usbtiny device, and connect it back in again.

9. issuing

`avrdude -c usbtiny -p m644'

now results in avrdude connecting to the ATMega644 and reporting that initialization succeeded and the fuses are okay. That is, it suddenly works fine.

I'm using a 6 foot long USB cable.

I am using the 'AVR breakout board' (SKU BOB-08508 from Sparkfun Electronics on http://www.sparkfun.com/ ) so that I can connect a 10-pin IDC connector to it and plug this directly into my breadboard with the ATMega644 circuit. I have the breakout board connected to the power and ground on the breadboard.

Breakout Board's Reset pin is connected to pin 9 of the Atmega644
Breakout Board's MISO pin is connected to pin 7 of the Atmega644
Breakout Board's SCK pin is connected to pin 8 of the Atmega644
Breakout Board's MOSI pin is connected to pin 6 of the Atmega644

Pins 10-11 on the AtMega644 are connected to VCC and ground. Each pin has one leg of an 0.1uF ceramic capacitor (marked "104Z") installed on it to smooth out the VCC.

Pins 30-31 are connected to VCC and ground, the same as above, complete with ceramic capacitor.

Pin 4 (PB3) is connected to an LED which is connected to a 150 Ohm resistor.

All other ATMega644 pins are left floating.

I wish I could test the usbtinyisp programmer for soldering defects of my own making...I'm not sure why avrdude can't find the programmer after I connect power to the Mega644 circuit. But it does find both the programmer and the Mega644 once I unplug and replug the USB cable.

Now to continue testing this in Linux! I really want to do AVR development from a Linux account and I plan to submit a "Bugzilla" bug to the Redhat people because avrdude as installed doesn't seem to work for unprivileged users. Also, I think the USBTinyISP device can stand a little more testing as a circuit. The reason for wanting Linux to work doesn't really have noble open source roots...I just don't want to have to set up the laptop again and again each time I want to test something.

[Zero]

1. On some boxes for some reason everything doesn't get initialized the first time you plug it in. I briefly experienced this problem on Debian a while ago, but it stopped occurring after something had been updated. Having to plug in, unplug, then plug back in is so unbearable?

2. Permissions are likely being set by udev. You need to add a rule to udev for the dongle. Mine looks like:

Code: Select all

SUBSYSTEM=="usb_device", SYSFS{idVendor}=="1781", SYSFS{idProduct}=="0c9f", GROUP="avr", MODE="660", SYMLINK+="USBTiny" 

and is in the file:

Code: Select all

/etc/udev/rules.d/70-usbtiny.rules

on my system. I have a group called "avr" which I am a member of. Also, this maps the usb port the dongle is plugged in to to /dev/USBTiny with a symbolic link which is quite handy.

3. You should not disconnect a target board while the programmer is still plugged into the USB port.

4. It's hard to "fry" a chip with 5V and some bad code/instructions. About the worst you can do is screw up your fuse bits and find the chip not talking to you correctly or at all. If you ever encounter this situation, try resetting the fuses back to default.

5. 6 feet is a long USB cable. If conditions were poor (say you had it running next to a lot of power cables or something) you could encounter problems. At this point I don't think any of your problems are related to this though.

6. You can test for soldering defects using a multimeter. You want to use what is called a continuity test (usually a sound wave/speaker kind of symbol, often the meter will beep when continuity is established). If your meter does not have a continuity test, use your ohmmeter at the lowest setting and make sure you get very low or 0 readings between joints that should be made and very high numbers or infinity between points that should not be directly connected.