Xmega AU manual USB section is a work of fiction

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The USB section of the Xmega AU data sheet seems to be a work of fiction. Does anybody care?

On page 240 it shows the USB transaction complete FIFO registers (FIFOWP and FIFORP) to start off as zeros. That would cause trouble. Actually they start off as ones, as they should. The data sheet call the contents pointers. That seems confusing. Actually they are indexes. Or do they really use negative pointers in Norway? ;)

On page 234, it says when these negative indexes reach the end of the FIFO, they wrap to zero. Ouch,that would be more trouble. Actually they wrap to -1.

On pages 244 and 245 it says bits in the endpoint registers are cleared by writing a one or logical 0 to the bit location. I don't think so. Actually the bits are cleared by using the LAC (Load And Clear) instruction.

There are more things about the USB description that seem unnecessarily confusing to me. For instance the TOGGLE bit in the endpoint STATUS register . It seems to me you could spend a lifetime trying to figure out how to set it or use it. I thnk in fact, the hardware uses it and it is of no use to the software, and the software should not change it. If I'm correct, the datasheet sheet should tell the programmer to keep his cotton pickin' hands off it.

Somehow, in spite of this, the USB ASF seems to work okay. Obviously the programmer wrote the code first, and would have read the manual only if all else failed. Give that programmer a raise! ;)

The page numbers refer to the latest version of the manual. I think that is version F dated April 2013. Unfortunately at the bottom of page one it says version E dated January 2013. You have to scroll down to page 7 to see the correct version.

If I am wrong about this stuff, please let me know. Otherwise I think this should be sent to Atmel.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Agreed. The manual confused me more than it helped me. Thank goodness the ASF files worked

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a related problem. We are trying to configure the ATXMEGA128A1U USB interface and our starting point is taken from the ASF files of the ATAVRXPLAIN board (The Evaluation board of the ATXMEGA128A1). Therefore the BOARD is defined as :

BOARD=XMEGA_A1_XPLAINED

In order to use the USB stack, we need to define the AU part, to allow moving from the old A series Xmega128 component to the newer AU series part.

Any ideas as to where and how this should be defined?

Any help would be greatly appreciated!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't remember all the details of my ASF build. I remember it was easy, so I was probably lucky. I don't remember what project I selected to start with. I built a USB CDC thing and it worked. This project uses a USART as well as the USB. If I connect a terminal emulator to the virtual serial port created by usbser, and connect another terminal emulator to a real comm port connected to the USART (I have real com ports on my computer), when I type on one terminal emulator, it is displayed on the other.

I built it with Atmel Studio. I'm using a 128a4u. When I bring up this project I see ATxmega128a4u up there in the ribbon.

The only thing I remember changing was src/Config/conf_board.h. I changed the USART port to D0.

I messed around with LUFA after I did this, and I tend to confuse one with the other.

The 128a1 you mentioned doesn't have built in USB hardware, so I'm not sure that would be a good starting point. I seem to remember the 128a1U had a silicon bug. Maybe I saw that in the code when I was working with LUFA.

I'm now using my own code, so the ASF is ancient history in my old brain. I still will use the ASF build occasionally to compare its performance with mine.

Oh wait a minute. I have the xplain board. I think that thing has another chip that does the USB. An AT90 chip, if I recall. I don't think that project is what you want.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

steve17 wrote:
The USB section of the Xmega AU data sheet seems to be a work of fiction. Does anybody care?

Doubt it. Atmel only seems to care about getting people to use ASF, which is so far out of the realm of possibility for me it isn't even funny.

I ended up taking the ASF codebase and *HEAVILY* instrumenting it, such that every single macro in the entire USB subsystem had the side effect of writing out a detailed trace of every single register operation in the entire system. Some python scripts decoded that into something I could actually read, and I think I might have even interleaved that with captures from a Saleae Logic USB trace.

I then painstakingly worked through writing my own codebase with identical tracing, until the traces "matched".

Suffice it to say, it was a lengthy process of swearing at Atmel. In the end I finally ended up with a functioning stack of my own, which I've attached.

I wouldn't call the USB section *complete* fiction, but it's darn close.

Unfortunately, all the other Xmega USB stacks I've found are either almost as complicated, or they're far enough off the mark that either they don't work, or I have no idea how they manage *to* work. They provided *some* degree of insight, but not as much as ripping into ASF.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I also "instrumented" the ASF, but maybe not as much as you. I logged all the setup packets and the responses.

I've now got my own code working for the CDC protocol. This code is much easier for me to understand because I wrote it and it is only for the Xmega, and at this point, only for CDC. It's all in one folder.

I've found the driver Win7 uses for CDC, usbser.sys, has it's problems. One problem is it stops polling the in endpoints eventually. I don't know why it stops. Maybe I'm doing something wrong that triggers this. I also know that usbser can cause a blue screen, but since I've got my code working right, that hasn't happened.

I may want to use a different USB protocol. Maybe Mass Storage or HID.

I spent a long time getting my code to work. I didn't swear much at Atmel, except their fictional account of how their USB module works. I did swear at Microsoft's usbser.sys and also at the nincompoop that designed the CDC protocol. ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for this information. I finally got the ATXMEGA384's USB peripheral working, but for a while I thought I was losing my mind.

I'm no brain surgeon, but I did get the 32U4 working without much trouble thanks to a well written datasheet. All the documents I've read for ATMEGAs have been excellent.

The USB section of the XMEGA family datasheet is a complete mess, full of awkward language, ambiguous logic, omissions, typos, outright lies and contains not a single code example.

It's clear whoever wrote this document was not a native English speaker and hasn't ever used the hardware he was documenting.

The mind boggles at how many man-hours have been and will be wasted trying to get the XMEGA to work because of Atmel's obvious cost cutting.

Does Atmel/Microchip care? It would appear they don't since they haven't published a proper document despite having years to do so.

"Just use ASF" isn't a valid answer. Some of us still program these things in Assembly.

This experience had me looking seriously at an MSP430.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have a look here: https://github.com/kuro68k/usb_k...

 

That should be easier to follow than the ASF code. My goal, if I ever find time, is to do a complete, clean stack from the ground up.

 

As for Atmel's documentation, it's above average I'd say. Most MCU documentation is far worse. Look at the PIC24 stuff, for example, or anything from Texas.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

redtail wrote:
It's clear whoever wrote this document was not a native English speaker
Pretty sure Xmega were done by Atmel's French team - same ones who did the early ARM stuff too - which is why there's quite a lot of similarity in peripherals.