Avrdude, stk500 usb, Mac?

WTF is the device that I give after the “-P” option to avrdude? Olimex claims it’s a USB CDC device, so it “doesn’t need drivers”. So what, exactly, should I expect to see in /dev? I’ve got nothing named usb or USB anything, and the only “cu” devices are for cell phones. I’ve been Googling away, no answer yet.

I went through this same song and dance with PIC programmers, this looked more promising from the docs, but it’s not looking so good now.

AHA.

Following the mention of “updated firmware drivers (installed from a PC)” ( viewtopic.php?t=13839 ) I borrowed my wife’s computer (Mac with VMWare with XP) and te-di-ous-ly installed the drivers and the firmware upgrade software. Christmas, this is slow.

And with the driver installed, the updated installed and running, pins 1 and 3 shorted, light blinking red/green just as the doc describes, it’s not working. not COM1, not COM2, not COM3.

I made my way to device manager, verified that every single setting matched what was described in the doc, ensured that it was COM3, and it Did Not Work.

Is it too much to ask, if a device is claimed to support a Macintosh, that it is actually tested on a Macintosh?

Be sure that avrdude has USB support. Either use Crosspack-AVR or MacPorts; compiling by hand is not recommended.

For the -c option, so far stk500v2 is less wrong than anything else I have tried. You can see that it figured out that it wanted to talk to the USB.

HOWEVER, it is still not working.

Sample output:

/usr/local/CrossPack-AVR/bin/avrdude -c stk500v2 -p t13 -P usb -v

avrdude: Version 5.6, compiled on Apr 15 2009 at 17:54:59
        Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

        System wide configuration file is "/usr/local/CrossPack-AVR-20090415/etc/avrdude.conf"
        User configuration file is "/Users/dr2chase/.avrduderc"
        User configuration file does not exist or is not a regular file, skipping

        Using Port                    : usb
        Using Programmer              : stk500v2
avrdude: usbdev_open(): did not find any USB device "usb"

Specifying the USB serial number (or xx or ??) also fails in all these cases:

-P usb:OL22B4D000115CD

-P usb:15:CD

-P usb:22B4D000115CD

-P usb:B4D000115CD

-P usb:15CD

-P usb:OL:22:B4:D0:00:11:5CD

-P usb:??

-P usb:xx

System Profiler reports:

Olimex AVR-ISP500:

 Product ID:    0x000c
 Vendor ID:    0x15ba
 Version:    1.03
 Serial Number:    OL22B4D000115CD
 Speed:    Up to 12 Mb/sec
 Manufacturer:    Olimex Ltd.
 Location ID:    0x1a200000
 Current Available (mA):    500
 Current Required (mA):    100

My negative, but accurate, comments were removed from the product page. No help yet from Olimex support; I do not think that they should advertise this product as working on the Mac.

I cant help you as im not a Mac user, but i feel your pain on the olimex support issue. Last time I needed help it was difficult to obtain and when i finally got it, it was a one liner. I never bought another olimex product sense that.

I have the Olimex STK500 clone working on my Intel 15" Macbook Pro.

This is a line from the Makefile:

PROGRAMMER = -c stk500v2 -P /dev/tty.usbmodem1d11

The XXXX in tty.usbmodemXXXX changes sometimes I believe.

ls -l /dev/tty.usbmodem* should help you find what you need.

ls -l /dev/tty.usbmodem* should help you find what you need.

Assuming that what I need is:

bash-3.2$ ls -l /dev/tty.usbmodem*
ls: /dev/tty.usbmodem*: No such file or directory

(You should really also tell me what you see, even though I already know what you see – if I were clueless enough to need that suggestion, I would not know what you see, and would remain puzzled.)

Assume that I am really not a dummy. Assume that I know how to use google, and that I have spent a lot of time on this. I don’t want the obvious answer-for-a-stupid person – I want to know what to do when that doesn’t work.

I assume there is something preventing the usbmodem from coming into existence. That something would be, what?

what do you see in System profiler? It would be useful to know if there are differences there.

and PPS, what version of MacOS are you running?

I am 10.5.6, generally up to patch level, generally I do NOT muck around with device drivers etc.

dr2chase:
(You should really also tell me what you see, even though I already know what you see – if I were clueless enough to need that suggestion, I would not know what you see, and would remain puzzled.)

I'm sorry you're frustrated, but I'm just someone trying to help you -- no need to get snippy.

dr2chase:
what do you see in System profiler? It would be useful to know if there are differences there.

and PPS, what version of MacOS are you running?

I am 10.5.6, generally up to patch level, generally I do NOT muck around with device drivers etc.

OSX: 10.5.6

I’m connecting it directly to a USB port on the notebook – not through a hub.

It appears I have a more recent firmware than you (1.04).

Olimex AVR-ISP500:

  Product ID:	0x000c
  Vendor ID:	0x15ba
  Version:	1.04
  Serial Number:	OL22AEE00011593
  Speed:	Up to 12 Mb/sec
  Manufacturer:	Olimex Ltd.
  Location ID:	0x1d100000
  Current Available (mA):	500
  Current Required (mA):	100
reykjavik:/Users/nall% ls -l /dev/tty.usb*
crw-rw-rw-  1 root  wheel    9,   6 May  6 07:22 /dev/tty.usbmodem1d11

from dmesg:

AppleUSBCDCACMData: start: InterfaceMappings dictionary not found for this device. Assume CDC Device...
AppleUSBCDC::createSerialStream NON WAN CDC Device 
AppleUSBCDC::createSerialStream using default naming and suffix...
AppleUSBCDCACMData: Version number - 3.2.12, Input buffers 8, Output buffers 16

because I tried to do the firmware upgrade on my neighbor’s Dell, and for whatever reason (I followed directions, I looked at the pictures, things were identical) the firmware updater either claimed the com port did not exist (for some values of com port) or claimed that there was timeout (for other values of com port).

In all cases, the com port was 1, 2, 3, or 4, as recommended in the documentation.

Also, dmesg (“sudo dmesg”) says:

       0        0 AppleUSBCDCACMControl: getFunctionalDescriptors - Descriptors are incorrect, checking...
AppleUSBCDCACMData: start: InterfaceMappings dictionary not found for this device. Assume CDC Device...
       0        0 AppleUSBCDCACMData: start - Find CDC driver failed

So, officially, “failed”.

My two guesses as to what is wrong are that (1) the programmer is ever-so-slightly busted (but not very – since it clearly introduces itself to the USB, and all the blinky lights behave exactly as expected) or (2) that the programmer actually gets USB a little bit wrong, and this always fails on a Mac, and sometimes fails on a PC, and thus it happens to fail on my neighbor’s PC.

Sorry about the snippy, but this stuff has been not working for me, I’ve invested a lot of time in debugging it, and Olimex and Sparkfun have not helped yet. I’m a little mystified how it serves their interests to have someone kvetching about their products, going over the failure in detail, and not getting any help – I’m writing up “how I got started with a microcontroller on a Mac” (because, having Googled for it a lot, there’s a lot of conflicting and/or sketchy information), and it’s pretty clear that the first piece of advice will be “do not buy an Olimex USB programmer”.

dr2chase:
because I tried to do the firmware upgrade on my neighbor’s Dell, and for whatever reason (I followed directions, I looked at the pictures, things were identical) the firmware updater either claimed the com port did not exist (for some values of com port) or claimed that there was timeout (for other values of com port).

For what it’s worth, I did the firmware upgrade in Parallels VM using WinXP as the guest OS. I remember having to short 2 wires and then the ordering of plugging in the device and running the updated seemed sensitive.

That said, I’ve had zero issues with this thing since that.

So you used Parallels on a Mac to do the update?

Because I tried VMware (see above), and it did not work.

The pins to short are 1 and 3 – I just bent a little piece of wire and stuck it in the end of the 10-pin connector, and it did the red-green thing as expected.

I did also notice the careful talk about the order of plugging in, running updater, etc., and did try several permutations. I think I tried them all, but since I did not document exactly what I tried, who knows? (Thus my snippiness about that saying exactly what to do and exactly what you will see – I specifically recall the Olimex instructions saying that I “may” remove the jumper after a certain step. “May”? That’s insane – the instructions should not contain unnecessary steps that multiply the possible set of paths through the upgrade. Either the jumper stays in, or the jumper comes out, but not either/or.)

Yes, Parallels 4.0 + WinXP Pro is all I used.

I know you’ve read all this stuff, but just for completeness:

First, I installed the USB drivers from the Olimex site.

http://www.olimex.com/dev/avr-isp500.html

Then when I plug in the device I get a Virtual COM like:

http://skitch.com/nall/bqk1k/olimex-drivers

Now I unplug and short pins 1-3 and plug back in and get red/green blink. Now I get a bootloader device:

http://skitch.com/nall/bqk1i/bootloader

Now I run the updated and use the COM4 (as shown in that last screenshot). I see “Target Found” and Select the firmware (use the one in my screenshot):

http://skitch.com/nall/bqkum/target-found

I click update and the light blinks green on and off (no red).

When done, LED stays green. Using the wrong firmware image (among other things I’m sure) can make it stay a solid red after the update is complete.

Thank you. That is the sort of information I would hope to see from the vendor (excellent use of arrows, by-the-way). I just checked, they do specifically leave out the bit about how the device name (should) change.

I’ll give it another try tonight (late afternoon, your time).

Haven’t had access to a windows box yet. Maybe later, when I’m in a mood to pound nails with my forehead, because…

USBtiny kit arrived in the mail; 50 minutes elapsed time from sitting down with the soldering iron, to first program blinking the LED in the programmer. Sparkfun should really, really, sell this as an alternative to the Mac users, because this worked exactly as predicted. For example:

avrdude -p t13 -c usbtiny -P usb -v

avrdude: Version 5.5, compiled on May  3 2009 at 12:43:48
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         System wide configuration file is "/opt/local/etc/avrdude.conf"
         User configuration file is "/Users/dr2chase/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port            : usb
         Using Programmer      : usbtiny
         AVR Part              : ATtiny13
         Chip Erase delay      : 4000 us
         PAGEL                 : P00
         BS2                   : P00
         RESET disposition     : dedicated
         RETRY pulse           : SCK
         serial program mode   : yes
         parallel program mode : yes
         Timeout               : 200
         StabDelay             : 100
         CmdexeDelay           : 25
         SyncLoops             : 32
         ByteDelay             : 0
         PollIndex             : 3
         PollValue             : 0x53
         Memory Detail         :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65     5     4    0 no         64    4      0  4000  4000 0xff 0xff
           flash         65     6    32    0 yes      1024   32     32  4500  4500 0xff 0xff
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          2    0      0     0     0 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00

         Programmer Type : USBtiny
         Description     : USBtiny simple USB programmer, http://www.ladyada.net/make/usbtinyisp/
avrdude: programmer operation not supported

avrdude: Using SCK period of 10 usec
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9007
avrdude: safemode: lfuse reads as 6A
avrdude: safemode: hfuse reads as FF

avrdude: safemode: lfuse reads as 6A
avrdude: safemode: hfuse reads as FF
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Or, from the makefile modified from the Instructable project:

avrdude -p attiny13 -c usbtiny               -E reset  -U flash:w:LED_Demo.hex 
avrdude: WARNING: -E option not supported by this programmer type

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9007
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "LED_Demo.hex"
avrdude: input file LED_Demo.hex auto detected as Intel Hex
avrdude: writing flash (134 bytes):

Writing | ################################################## | 100% 0.12s



avrdude: 134 bytes of flash written
avrdude: verifying flash memory against LED_Demo.hex:
avrdude: load data flash data from input file LED_Demo.hex:
avrdude: input file LED_Demo.hex auto detected as Intel Hex
avrdude: input file LED_Demo.hex contains 134 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.07s



avrdude: verifying ...
avrdude: 134 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Good to hear you can make some progress at least.

You might suggest this on the “New Product Ideas” forum.

I got the Olimex to work by running the updater in Vista under VMware on OSX 10.5.6 following nall’s procedure.

The little wire trick was the key.

I unplugged the device stuck the wire in, plugged it back in, connected it to VMware (it showed up as “Modem” and not as Olimex anything) and ran the updater. It enumerated as a different port (COM6) than the ISP500 does (COM3). Flipping back to OSX it shows up as a new /dev/tty.usbmodem* or /dev/cu.usbmodem*

I haven’t tried programming it yet but putting the right /dev address into avrdude’s -P parameter made it work up to “unknown status” which means theres no MCU connected (there wasn’t).