Atmel USB Framework

liamstask wrote on Wednesday, November 19, 2008:

I’m trying to port the Atmel USB Framework v1.4 ( to my FreeRTOS based system.  I’m on a SAM7X256 in a GCC-based environment (GNUARM and CrossWorks).  I’m interested in doing this since the USB framework is event driven, and offers a flexible way to support the included USB profiles (hid, cdc, mass storage, etc.). 

I’ve started with the CDC example in the most current software pack for the AT91SAM7X-EK, v1.4.  The example builds just fine and it connects to my desktop as a CDC device successfully.  But the framework code unfortunately includes a bunch of tracing and pio code that I don’t want, but nothing that affects the operation of the USB system as far as I can tell, so I’ve been snipping that stuff out. 

In my codebase, I’ve wrapped the single USB ISR in FreeRTOS style with a naked wrapper, and it seems to get called successfully a couple times on init of the USB system, but the USB system never configures itself successfully. 

One odd thing I’ve noticed in the CDC example is that if I disable the DBGU tracing that’s enabled just before USB init, then things don’t work either.  Enabling the DBGU in my codebase does not help (that was just some of my paranoia trying that out).

Anybody played with this?  Any thoughts?  Thanks!

edwards3 wrote on Thursday, November 20, 2008:

The debug statements in the Atmel code seem to completely change how the structures are accessed. Never figured it out. Are you trying to port AVR32 code to an ARM7? Are the peripherals compatible?

liamstask wrote on Saturday, November 22, 2008:

I actually did end up getting this sorted out.  As mentioned, I removed all instances of tracing or LED blinking or whatever other weirdnesses they slipped into the USB framework code, and none of that seemed to have any real impact on the actual USB operation.  It was the Atmel software pack for the SAM7X256 so I didn’t think there should be peripheral compatibility issues (as in a AVR32 to ARM7 port).

Turns out the thing I had been missing was that some of the hardware init stuff was in the example code’s startup code, whereas in the previous USB implementation, it had been in the USB init code and I had just overlooked it as I was shuffling everything around.  Once I got that working, the USB CDC interface comes up like a champ and reads and writes as expected.  You can browse my altered version at