I just stumbled across a problem using the FreeRTOS USB task (from the lwIP_Demo_Rowley_ARM7 demo) on the AT91SAM7X-EK board and thought I would share it with anyone else in a similar situation.
I have been using this board to get familiar with FreeRTOS, lwIP and a number of other things before I design a custom board for my final application. I had previously completed an Eclipse project that had an AT45DB642D task (this is the dataflash on the AT91SAM7X-EK board). The task performed a series of tests on the dataflash and displayed the results on a web browser using lwIP. The next step in the roadmap was to add USB as this will be a great way to initially configure my custom board. Using the above demo as a guide, I added the USB to my new project but it didn’t work. I finally tracked the problem down to the USB-CDC.c code which manipulates PA16. The comments in the code indicated that this controlled the USB pullup resistor, but looking at the schematics for the AT91SAM7X-EK showed that PA16 was used for SPI0_MISO which is connected to the dataflash device. It appears that the AT91SAM7X-EK doesn’t have the ability to control the pullup resistor as this is an integral part of the STMicroelectronics USBUF02W6 part. I commented out all of the PA16 related lines in the code and everything started working. Wondering how this could have happened, I decided to take a look at the Atmel AT91SAM7S-EK schematics (the version of the board WITHOUT Ethernet). Sure enough, this board doesn’t have dataflash but it does have the ability to control the USB pullup with - you guessed it - PA16.
The latest versions of board.h from the Atmel at91lib distribution check for a #define of the chip type to pull in the appropriate *.h chip definition file. This definition could also be used within the USB-CDC.c code to either enable or ignore the use of PA16.