Re: trouble enumerating USB device; and lost USARTF TX...

[Dean Camera]

Peter,

Whoops-a-daisy, just noticed this old thread wasn't answered. Are you
still having trouble with this, or has my inexcusable tardiness
allowed you to find a solution?

What version of LUFA are you using? I have had success with LUFA
(recentish versions) on the XMEGA devices using the CDC class in the
past, although past history makes me wary of releasing non-polished
demos to show this on this list. A copy of your project zipped up
either here or directly to myself would allow me to look over this for
you in greater depth, but I suspect a badly set or missing LUFA
compile time configuration option. The breakage of PORTF's USART is a
little mystifying me at first glance - LUFA should not be modifying it
unless you use the XMEGA USART driver in LUFA.

Cheers!
- Dean

On Oct 1, 1:47 pm, Peter <peter.lonnebr...@gmail.com> wrote:
> Hello Dean & all group members,
>
> I'm wrestling with a problem on an ATxmega64a3u. I have lot's of code
> already working on it, so far using USARTS for serial communication.
> No pins left to use JTAG, I'm basically printf-debugging using my trusted
> serial ports.
> Since the usb-port will be used in the future (will at least add a
> boot-loader later), I thought now was the time to try adding a USB stack.
>
> I've added LUFA and code from the CDC (VirtualSerial) demo and it compiles
> just fine. Descriptors left unchanged, except for the vendor/model strings.
> I copied the small pieces of code from VirtualSerial.c needed for
> initialization and added the polling/processing to my main-loop.
> Connecting the device to my computer, all I get is
>
> The IOUSBFamily is having trouble enumerating a USB device that has been
> plugged in.  It will keep retrying.
> The IOUSBFamily was not able to enumerate a device.
> The IOUSBFamily gave up enumerating a USB device after 10 retries.
> The IOUSBFamily was not able to enumerate a device.
>
> Fair enough; I start my printf-debugging routine—but now my debug serial
> port (USARTF0) is broken, no TX, but RX still works (I'm updating a
> 7-segment display based on data from the serial port).
> Since RX works, I guess the baudrate is correct, which means the system
> clock is still correct.
> Commenting out the "USB_Init()" call restores everything back to normal
> (and no IOUSBFamily-printouts in the log).
>
> The questions to all analytical minds out there is: a) why does the
> enumeration fail and b) why is USARTF0 affected by a call to USB_Init?
>
> Out of frustration, I tried ripping parts of the "monolith/XMEGA-USB" boot
> loader (which seem to have ripped parts of LUFA) and got the enumeration
> working with that, no problems whatsoever.
> Since I'd like to have the CDC code, I switched back to the full LUFA stack.
>
> Dean: I'm impressed by the amount of work you have put into this project as
> well as by the quality of the code. Great, great work.
> Once I get this up and running, I'll have no problems convincing my
> colleagues to purchase a commercial license.
>
> Kind regards,
> Peter
>
> (Btw; the board is of custom design, the xmega64a3u runs at 16Mhz using an
> external oscillator.)

[Dean Camera]

Hi Scott,

Are you using the Arduino Leonardo bootloader? If so, you are most
likely hitting the issue discovered by Simon Inns, where the
bootloader doesn't clean up a few bits and pieces which prevents LUFA
from enumerating correctly. To fix it, you need to use the latest LUFA
trunk version rather than the release version (www.lufa-lib.org/latest-
archive). You can read more about getting LUFA working on the Leonardo
here:

http://fourwalledcubicle.com/blog/2012/08/lufa-and-the-arduino-leonardo/

Cheers!
- Dean

On Jan 12, 9:00 am, Scott Lyons <scottaly...@gmail.com> wrote:
> Sorry to dredge up an old topic, but I'm experiencing something similar.
> I've got an Atmega32u4 (Arduino Leonardo) and I've tried both the low-level
> GenericHID and low-level Keyboard demos and neither get into the
> Enumeration stage. I was able to debug a little by hooking up a serial LCD
> that I have and from what I could see it was never being configured by my
> host. As far as I could tell, EVENT_USB_Device_Connect was being called,
> but EVENT_USB_Device_ConfigurationChanged isn't.
>
> I'm still learning my way around this, but I'd be glad to help out if you
> want me to do any digging.

[Scott Lyons]

I used that blog post to get started, but I am using the latest trunk of LUFA from git. And I am using the stock Leonardo boot loader. Do I have to to replace the boot loader then?

Thanks for your reply!

> --
> You received this message because you are subscribed to the Google Groups "LUFA Library Support List" group.
> To post to this group, send email to lufa-s...@googlegroups.com.
> To unsubscribe from this group, send email to lufa-support...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/lufa-support?hl=en.
>

[Scott Lyons]

Turns out that I was using the Git trunk, but that I forgot to copy the F_CPU value after pulling your latest changes. Putting in the right values solved the problem for me! Sorry to have dragged it back up.

[Peter]

Thank you for your response!

...now that I at last found your answer. (I was expecting a notification from google groups.)

I have been working on other parts of the software for quite some time now and the USB-support has been a rather low priority.

The problem has now changed. It seems to be mostly ATxmega64a3u-specific.

I just recently picked this up again (and found the reply from you). Our firmware code has changed a lot since the last attempt so I figured I'd start from scratch with the USB support and cloned LUFA from git. As a more "stand alone" project I decided to start with getting a USB bootloader up and running. However, I still run into problems.

At first I started with the stripped down LUFA bootloader branch used by nonolith, which I got partially working after giving up on Avrdude and switching to the programmer in Atmel Studio (the bootsection address seemed to be off). The device is now correctly identified by the computer as soon as the USB-cable is connected, but the nonolith-provided python script reports a bad checksum whenever I try to program my firmware.

This is where I cloned the LUFA git repository and tried to compile the DFU boot loader — which seems to compile fine for any other microcontroller than mine: the atxmega64a3u.

The avr-gcc version (4.7.0) I have doesn't even support this controller, but I've used the mcu-setting set to atxmega64a3 combined with a copy of the iox64a3u.h from the Atmel Studio installation to overcome this problem. I've also tried using the avr-gcc packaged with CrossPack, which does support the atxmega64a3u controller.

Whichever combination of compiler and header files I choose, compiling the LUFA DFU-bootloader gives me the following errors:

....avr/boot.h:115:4: error: #error AVR processor does not provide bootloader support!

....avr/boot.h:125:4: error: #error Cannot find SPM Enable bit definition!

I tried using the header files from the Atmel Studio 6 AVR-toolchain, the CrossPack distribution and the avr-gcc available from the "homebrew" OS X packet manager (gcc 4.7.0).

It seems to me that the problem is related to the mcu-capabilities defined in the header files.

Do you or anyone in the forum here have any experience with the atxmega64a3u?

Cheers—

Peter

[Peter]

A simple test showed that this code:

#include <avr/io.h>

#include <avr/boot.h>

void main(void) {}

compiled with

#> avr-gcc -mmcu=atxmega64a3u -c boot_source.c

results in

avr/boot.h:115:4: error: #error AVR processor does not provide bootloader support!

avr/boot.h:125:4: error: #error Cannot find SPM Enable bit definition!

Which I believe is an indication to one of the problems... This MCU should allow self-programming and bootloaders according to the documentation. I've opened a ticket with Atmel.

Anyone else using the ATxmega64a3u?

[Dean Camera]

The XMEGAs aren't supported by the LUFA bootloaders - or via the avr-
libc <avr/boot.h> header, for that matter. The reason is that they
have a dedicated NVM (Non Volatile Memory) controller unit in the
parts that manages self-programming that has to be used, instead of
the old SPM instruction. It's possible to port the bootloader, but you
would need to rip out all the avr-libc bootloader function calls and
replace then with calls into the NVM controller on the XMEGAs.

Cheers!
- Dean

On Feb 11, 2:26 pm, Peter <peter.lonnebr...@gmail.com> wrote:
> A simple test showed that this code:
>
> #include <avr/io.h>
> #include <avr/boot.h>
>
> void main(void) {}
>
> compiled with
>

> *#> avr-gcc -mmcu=atxmega64a3u -c boot_source.c
> *

>
> results in
>
> avr/boot.h:115:4: error: #error AVR processor does not provide bootloader
> support!
> avr/boot.h:125:4: error: #error Cannot find SPM Enable bit definition!
>
> Which I believe is an indication to one of the problems... This MCU should
> allow self-programming and bootloaders according to the documentation. I've
> opened a ticket with Atmel.
>
> Anyone else using the ATxmega64a3u?
>
>
>
>
>
>
>
> On Saturday, February 9, 2013 3:50:15 PM UTC+1, Peter wrote:
>

> > *Thank you for your response!*
> > *
> > *

> > ...now that I at last found your answer. (I was expecting a notification
> > from google groups.)
>
> > I have been working on other parts of the software for quite some time now
> > and the USB-support has been a rather low priority.

> > The problem has now changed. It seems to be mostly* ATxmega64a3u*
> > -specific.

[Peter]

Thanks for your reply Dean,

I obviously misinterpreted the documentation.

I've started adopting the Atmel boot loader instead (from application note AVR1916).

Cheers!

Peter