Xmega AU manual USB section is a work of fiction

Log in or register to post comments
Go To Last Post
16 posts / 0 new
Author
Message
steve17
steve17's picture
Level: Raving Lunatic
Joined: Tue. Sep 7, 2004
Posts: 5818 View posts
Location: New York State
#1
Posted by steve17: Wed. Dec 4, 2013 - 12:18 PM
  • 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): 

Image icon page7.png

Tags:

AVR Microcontrollers, AVR XMEGA
Top
auxren
auxren's picture
Level: Rookie
Joined: Tue. Mar 6, 2012
Posts: 34 View posts
Posted by auxren: Wed. Dec 4, 2013 - 04:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
gilelgez
gilelgez's picture
Level: New Member
Joined: Tue. Sep 19, 2006
Posts: 1 View posts
Posted by gilelgez: Wed. Dec 4, 2013 - 08:30 PM
  • 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!

Top
steve17
steve17's picture
Level: Raving Lunatic
Joined: Tue. Sep 7, 2004
Posts: 5818 View posts
Location: New York State
Posted by steve17: Wed. Dec 4, 2013 - 10:34 PM
  • 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.

Top
omegahacker
omegahacker's picture
Level: Rookie
Joined: Wed. May 9, 2007
Posts: 22 View posts
Posted by omegahacker: Wed. Dec 4, 2013 - 11:48 PM
  • 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): 

File Custom USB stack header
Top
steve17
steve17's picture
Level: Raving Lunatic
Joined: Tue. Sep 7, 2004
Posts: 5818 View posts
Location: New York State
Posted by steve17: Thu. Dec 5, 2013 - 11:13 AM
  • 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. ;)

Top
redtail
redtail's picture
Level: New Member
Joined: Thu. Dec 10, 2015
Posts: 8 View posts
Posted by redtail: Tue. Sep 26, 2017 - 09:12 PM
  • 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.

Top
mojo-chan
mojo-chan's picture
Level: Raving Lunatic
Joined: Thu. Jan 24, 2008
Posts: 2087 View posts
Posted by mojo-chan: Wed. Sep 27, 2017 - 07:46 AM
  • 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.

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 91468 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Sep 27, 2017 - 08:15 AM
  • 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.

Top
mojo-chan
mojo-chan's picture
Level: Raving Lunatic
Joined: Thu. Jan 24, 2008
Posts: 2087 View posts
Posted by mojo-chan: Thu. Mar 8, 2018 - 11:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

steve17 wrote:
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.

 

Are you sure about that? I'm looking at the ASF code... Sorry the code posting is broken, but it does:

 

int8_t rp = USB.FIFORP;

i_fifo = 2 * (1 + ~rp);
ad = ((uint16_t) udd_sram.ep_ctrl) - i_fifo;

p_ad = (uint16_t *) ad;

 

 

udd_sram is a struct

 

struct udd_sram_data {

    uint32_t fifo[USB_DEVICE_MAX_EP + 1];

    USB_EP_t ep_ctrl[2 * (USB_DEVICE_MAX_EP + 1)];

    uint16_t frame_number;

};

 

 

So this gives us the following table:

 

RP i_fifo

0  2

1  4

2  6

3  8

 

 

I'm confused now. The datasheet says that the FIFO size is (MAXEP[3:0]+1)*4, so it's basically the number of endpoints (including the mandatory control endpoint) x4 bytes. And sure enough, the struct in the ASF used for this memory uses uint32s for the FIFO.

 

But that doesn't match the calculation in the ASF. It only multiplies by 2, so one 16 bit word per endpoint. It adds 1 to ensure the first element is at EPPTR-2. And sure enough the pointer extracted is a uint16, and the datasheet shows the FIFO as an L and H pair in the usual way for 16 bit pointer registers. The datasheet also says that new entries are at (EPPTR + 2 * FIFOWP), which accounting for precedence is 16 bits per table entry.

 

So something is wrong... The ASF code passes the USB2CV suite (which is an absolute bugger to get working) so I'm sure it works, which means either I'm and idiot (possible, even likely) or the FIFO isn't really 4 bytes per entry... right???

Top
Greg_Muth
Greg_Muth's picture
Level: Posting Freak
Joined: Sat. Dec 13, 2014
Posts: 1080 View posts
Location: Portland, OR, US
Posted by Greg_Muth: Thu. Mar 8, 2018 - 05:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@steve17 wrote:

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.

The version of the AU Manual I have has the same version/date on the first seven pages (and presumably the rest).

 

 

 

 

I've attached a copy.

Attachment(s): 

PDF icon XMEGA AU Manual.pdf

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Top
steve17
steve17's picture
Level: Raving Lunatic
Joined: Tue. Sep 7, 2004
Posts: 5818 View posts
Location: New York State
Posted by steve17: Fri. Mar 9, 2018 - 01:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The endpoint registers (that's what I call 'em) are in an array.   We pass the address of the first one to the hardware.

 

The fifo array sits just before the endpoint registers array.  The fifo indexes are based relative to that address of the endpoint registers we pass to the hardware, so the first one has an index of -1.

 

The next fifo has an index of -2, etc.  So you could say the fifo array works backwards.

 

To put it another way, there are two arrays that share the same starting point.  One goes up and the other one goes down.

 

A fifo entry with an index of zero would overlay the first endpoint register.  

 

The fifo entries are addresses of endpoints so are 16 bits (2 bytes).

 

​That's the way I remember it anyway.

Last Edited: Fri. Mar 9, 2018 - 01:34 AM
Top
mojo-chan
mojo-chan's picture
Level: Raving Lunatic
Joined: Thu. Jan 24, 2008
Posts: 2087 View posts
Posted by mojo-chan: Fri. Mar 9, 2018 - 08:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

steve17 wrote:

The endpoint registers (that's what I call 'em) are in an array.   We pass the address of the first one to the hardware.

 

The fifo array sits just before the endpoint registers array.  The fifo indexes are based relative to that address of the endpoint registers we pass to the hardware, so the first one has an index of -1.

 

The next fifo has an index of -2, etc.  So you could say the fifo array works backwards.

 

Correct

 

Quote:
A fifo entry with an index of zero would overlay the first endpoint register.  

 

The fifo entries are addresses of endpoints so are 16 bits (2 bytes).

 

​That's the way I remember it anyway.

 

I see what you are saying, but the actual FIFORP/FIFOWP registers do go to zero. You have to subtract 1 yourself and multiply by 2 to convert to a 16 bit address.

 

Which brings me back to the question above. Why does the datasheet say the FIFO total size is 4 bytes per endpoint?

Top
mojo-chan
mojo-chan's picture
Level: Raving Lunatic
Joined: Thu. Jan 24, 2008
Posts: 2087 View posts
Posted by mojo-chan: Tue. Mar 13, 2018 - 03:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, I can confirm that I was right about FIFORP/WP being zero indexed. Checks out with debug code and in the debugger.

Top
steve17
steve17's picture
Level: Raving Lunatic
Joined: Tue. Sep 7, 2004
Posts: 5818 View posts
Location: New York State
Posted by steve17: Thu. Mar 15, 2018 - 08:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ain't it nice we get no notifications when posts are made to threads we start?

 

I'm not sure what you mean about zero indexed.  When the chip is booted up, the fifo pointers are set to -1.  Here's a picture from the debugger.  Maybe you are using the simulator.

 

 

 

Here's what the manual shows.

 

 

 

Atmel insists the values in the read and write pointers start at zero and are incremented, BUT YOU HAVE TO ONES COMPLEMENT THEM.  Okay Atmel, whatever you say, but to me they start at -1 and are decremented.  Just don't try to tell Atmel that.  They get mad.  wink

 

 

P.S.  I only allocate FIFO memory equal to the size of a pointer times the number of endpoints.   However something I don't understand is how others count endpoints.  I consider the control out and the control in as 2 endpoints.  I guess some think of them as 1 endpoint.  Like endpoint 0 out and endpoint 0 in.

 

Actually that may be the official way according to the high priests of USB.  Or just the way Atmel does it.  We have to tell the USB hardware the max endpoint address.  I use 2. (0, 1, 2).  But I have 6 endpoints according to the way I count them. 

 

 

 

Last Edited: Thu. Mar 15, 2018 - 08:35 PM
Top
mojo-chan
mojo-chan's picture
Level: Raving Lunatic
Joined: Thu. Jan 24, 2008
Posts: 2087 View posts
Posted by mojo-chan: Fri. Mar 16, 2018 - 10:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree it's immensely confusing. Take a look at this code from the ASF, which works:

 

</p>
<p>//** Decode TC FIFO</p>
<p>// Compute ep addr</p>
<p>rp = udd_get_fifo_rp();</p>
<p>i_fifo = 2 * (1 + ~rp);</p>
<p>ad = ((uint16_t) udd_sram.ep_ctrl) - i_fifo;</p>
<p>p_ad = (uint16_t *) ad;</p>
<p>// Compute ep</p>
<p>ep_index = (((uint16_t) * p_ad - ((uint16_t) udd_sram.ep_ctrl)) >> 3);</p>
<p>ep = (ep_index / 2) + ((ep_index & 1) ? USB_EP_DIR_IN : 0);</p>
<p>Assert(USB_DEVICE_MAX_EP >= (ep & USB_EP_ADDR_MASK));</p>
<p>

 

udd_get_fifo_rp() is just a macro that returns USB.FIFORP, because obviously you need a macro for that.

 

So the index into the FIFO is 2*(1+ ~FIFORP). Then the address of the FIFO entry is EPPTR - index...

 

</p>
<p>uint8_t i_fifo</p>
<p>int8_t rp;</p>
<p>FIFORP = 0b00011111;</p>
<p> </p>
<p>i_fifo = 2 * (1 + (~0b00011111));</p>
<p>i_fifo = 2 * (1 + (0b11100000));</p>
<p>i_fifo = 2 * (1 + (-32));</p>
<p>i_fifo = 2 * -31;</p>
<p>i_fifo = -62;</p>
<p>

 

And indeed the udd_reset_fifo() macro sets FIFORP to 0xFF.

 

But what I mean is that it wraps to 0x00 eventually, or at least the datasheet claims it does.

 

</p>
<p>i_fifo = 2 * (1 + (~0x00));</p>
<p>i_fifo = 2 * (1 + (0xFF));</p>
<p>i_fifo = 2 * (1 + (-1));</p>
<p>i_fifo = 2 * 0;</p>
<p>i_fifo = 0;</p>
<p>

 

The datasheet says the address is EPPTR + 2 x FIFORP, which as you say doesn't seem right.

 

 

Top