XMEGA port

[kuro68k]

Hi. I have started porting V-USB over to XMEGA. I have it compiling and the Windows PC sees an unknown USB device. Looking at the debugger it appears that packets are being received.

The first request that comes in is length 8, and looks like this:

Code: Select all

      bmRequestType   0x80   unsigned char{registers}@0x2066
      bRequest      0x06   unsigned char{registers}@0x2067

This is a request to read the device descriptor and looks valid. But the device is coming up as unknown and Windows doesn't seem to see the VID/PID, as if the response is not valid.

Has anyone else had success with this? I'm using a 128A3U and 16Mhz crystal for timing, with code being a slight variation of the 16MHz original. I'm using a virtual port so that single cycle access is possible, the same as on MEGA and TINY AVRs.

Any recommendations on good tools for debugging? I'm going to get my logical analyzer running when I find time.

[kuro68k]

I threw the code up on Github: https://github.com/kuro68k/vusb-xmega

[kuro68k]

Logic capture, looks like the response is bad perhaps?



http://i.imgur.com/DrwsClJ.png

[kuro68k]

Okay, it enumerates now. I have not tested it extensively but this is a good sign that everything is likely to operate smoothly.

For XMEGA there are a few instructions with different timing to MEGA/TINY AVR cores, and some architectural differences like not having the CPU registers mapped into memory space. I have overcome these issues and have code working at 16MHz.

To work at 16MHz you need a virtual port and two GPIO registers. Note that I'm talking about the internal GPIO registers, not I/O pins. I've tested using the internal pull-up on the D- pin, although it's out of spec. The virtual port is to allow SBI/CBI/IN/OUT single cycle access. GPIO0 is used to hold usbNewDeviceAddr and shave a cycle off an LDS. GPIO1 is used in place of a CPU register because as I mentioned registers are not mapped into address space.

Ported to 24 or 32MHz it should be easy to eliminate the need for GPIOs and probably for the virtual port as well. I don't have the time or inclination to do that though, all I came for is to create a bootloader that will fit in 4k, maybe even 2k. It currently stands at 2208 bytes with -Os and the HID example code.

Enjoy.