Re: [avrdude-dev] [bug #40831] LUFA AVRISP-MKII fails with avrdude 6.0.1

[Dean Camera]

Joerg Wunsch wrote:
> That's pretty normal though; only the control endpoint is usable in
> both directions, data EPs need one EP per direction.

Indeedy, each non-control endpoint accepts only IN or OUT data. However, 
it's perfectly legal to have two logical endpoints share the same index 
but with opposite directions, giving the 0x02 (OUT) and 0x82 (IN) 
endpoint addresses used on the legacy Atmel tools. The issue here is 
that on the AVR8 devices the endpoint address is dictated by its logical 
index in the device, so endpoint index 2 in the USB AVR8 can only be 
given the USB endpoint address of 0x82, or 0x02 - you can't assign 
different logical endpoints to arbitrary endpoint addresses.

To get around that for the AVRISP-MKII Clone firmware (since the Jungo 
drivers and Atmel tools assume the 0x02 and 0x82 endpoint addresses) I 
just swap the direction of endpoint 2 in the USB AVR to the direction 
needed at that point in time based on the higher level protocol. It's a 
nasty, nasty hack, but as long as both sides stick to the published 
protocol it works a treat. Where it falls down is when AVRDUDE tries to 
read data from endpoint 0x82 in the serial drain function when I've 
already flipped around the direction of the bank inside the AVR, causing 
a USB transaction failure (invalid endpoint, since according to the USB 
AVR controller, 0x82 doesn't exist any more at that point in time).


> Even though they are using a different chip on the USB
> interface, they have one EP per direction.

More advanced USB chipsets (XMEGA, newer UC3s, etc.) can freely allocate 
any logical endpoint address to any physical bank in the device, so you 
could allocate the first three endpoints to addresses 0x00, 0x02, and 
0x82. If i ever port my code to the XMEGAs it will work just fine 
without hacks, but carries the 3.3V restriction which makes it more 
difficult to quickly use on parts if you're just throwing together a 
programmer from your parts bin.


> If you tell me what to reproduce, I can run this through a hardware
> USB analyzer.  What hardware do I need?  I've got an RZRAVEN USB stick
> (employing an AT90USB1297) around, can I make that work?

Sure, that'll work fine. Presumably you have an AVR-GCC setup available (!) so just "git clone 
address@hidden:abcminiuser/lufa.git" or grab a tarball from https://github.com/abcminiuser/lufa/archive/master.tar.gz and extract 
it out. In the "Projects/AVRISP-MKII" folder edit the makefile "BOARD" value to "NONE" (this disables 
the LED twiddling code) and "make all" to generate the HEX file. I'm not sure if the RZUSBSTICK uses an 8MHz or 16MHz 
crystal, so set "F_CPU
" in the makefile accordingly.

By default, the firmware builds in the LibUSB compatibility mode, which uses the 
different 0x02 and 0x83 endpoints which breaks completely on the latest AVRDude as the 
heuristics doesn't find the new endpoint layout. To change this, comment out the 
LIBUSB_DRIVER_COMPAT in the "Config/AppConfig.h" header and recompile.

If you can't do the above, let me know what configuration (F_CPU, USB endpoint 
compatibility mode) you need and I'll generate a binary for you. Note that this 
will cause naughty SPI/USART output from the AT90USB1287 when trying to contact 
a programming target, which might break other hardware on your board if you 
don't disable it.


Cheers!
- Dean