usb/149283: avrdude unable to talk to Arduino board (via uftdi)

[Hans Petter Selasky]

The following reply was made to PR usb/149283; it has been noted by GNATS.

From: Hans Petter Selasky <hselasky at c2i.net>
To: freebsd-usb at freebsd.org
Cc: Marcin Cieslak <saper at saper.info>,
 Joerg Wunsch <joerg_wunsch at uriah.heep.sax.de>,
 FreeBSD-gnats-submit at freebsd.org
Subject: Re: usb/149283: avrdude unable to talk to Arduino board (via uftdi)
Date: Wed, 4 Aug 2010 22:53:39 +0200

 On Wednesday 04 August 2010 22:21:32 Marcin Cieslak wrote:
 > On Wed, 4 Aug 2010, Joerg Wunsch wrote:
 > > As Marcin Cieslak wrote:
 > >> Checked with the same hardware (dual-boot) and Microsoft
 > >> Vista (with arduino-0018 IDE) and the board can be
 > >> contacted and programmed without any problems.
 > > 
 > > Your check on Windows has been using a stock AVRDUDE (e.g., a WinAVR
 > > compilation), too?  Or another tool?
 > 
 > On Windows I have used arduino Java IDE. Arduino IDE distribution
 > actually includes a whole WinAVR stack including avrdude.exe,
 > but I didn't pay attention what is actually used.
 > I will reboot to Windows now and check the commandline invocation.
 > 
 > On FreeBSD arduino the Java IDE tries to use avrdude and fails the same
 > was as from commandline.
 > 
 > > IIRC, the Arduino bootloader requires some special tricks in order to
 > > talk to it.  I think AVRDUDE v5.10 still lacks that feature.  Could
 > > you try the SVN version of AVRDUDE?
 > 
 > AVRDUDE is mentioned for example here
 > http://www.arduino.cc/playground/FreeBSD/CLI as the tool to use.
 > 
 > I have tried "-c arduino" or "-c stk500v1" with trunk and I get still
 > the same affect as with 5.10 (Programmer timeout).
 > 
 > What maybe important: TX/RX LED on the board don't react at all
 > when trying to use avrdude (there is only a single blink
 > on firmware LED - which means bootloader start).
 > 
 > With Windows - TX/RX indicated clearly some activity.
 > 
 > > (I don't see a GNATS ID in the subject.  Has this been actually filed
 > > via send-pr?)
 > 
 
 You can try to comment out:
 
         /* clear stall at first run */
         mtx_lock(&sc->sc_mtx);
         usbd_xfer_set_stall(sc->sc_xfer[UFTDI_BULK_DT_WR]);
         usbd_xfer_set_stall(sc->sc_xfer[UFTDI_BULK_DT_RD]);
         mtx_unlock(&sc->sc_mtx);
 
 In uftdi_attach in sys/dev/usb/serial/uftdi.c.
 
 --HPS