I have been using five of the AT91SAM9260-EK development boards for several months now without problems. I received two AT91SAM9G20-EK boards to evaluate since we are planning on switching over to the 9G20 part.

My system consists of the Atmel development board and a CSR Bluetooth development kit connected with a USB cable.
I am running the same code on both the 9260 and the 9G20 with the exception of different PLL settings. The USB clock is running at the same speed on both systems.

I have been having problems with the USB Host controller returning DEVICENOTRESPONDING transfer errors on the 9G20 even when my software is not talking to the CSR device or the USB Host controller. The software has set the controller up to perform periodic transfers on two endpoints. Looking at the USB traffic with a bus analyzer I see tons of USB IN packet requests being NAKed by the CSR device since there is no data to be returned. Once in a while a NAK appears to not be sent by the CSR device (or it is squashed) and after three missed NAKs I get the DEVICENOTRESPONDING error. I can get the error to occur more regularly by accessing the SD card or using the USB device port. It also appears that if I reduce the MCLK/PCLK the errors do not occur as frequently.

As I stated everything works great on the 9260, I have been running the 9260 board for months with out ever seeing this error. If I switch from the AT91SAM9260-EK to the AT91SAM9G20-EK I get the errors immediately. It seems like it is a USB signal quality problem but I can not see any problems on the cable.

Has anybody been using the USB Host port on the AT91SAM9G20-EK development board? Any other suggestions would be greatly appreciated.

I can't say that I have, but a wild guess is that this sounds tremendously like a missed interrupt.

[Again, only a wild guess.]

I'm running linux on my 9g20's board,and when I insert the usb sound card or u-disk into 9g20's usb host port,it seems that there are some error information like:
usb 1-1: new full speed USB device using at91_ohci and address 2
usb 1-1: device descriptor read/64, error -71
usb 1-1: device descriptor read/64, error -71
usb 1-1: new full speed USB device using at91_ohci and address 3
usb 1-1: device descriptor read/64, error -71
usb 1-1: device descriptor read/64, error -32
usb 1-1: new full speed USB device using at91_ohci and address 4
usb 1-1: device not accepting address 4, error -71
usb 1-1: new full speed USB device using at91_ohci and address 5
usb 1-1: device not accepting address 5, error -71
hub 1-0:1.0: unable to enumerate USB device on port 1

and sometimes it seems OK,does 9g20's usb host stable?

Hi,

Same findings, using the 9260-EK boards for more the 6 months, without problems.
For the 9G20 boards, USB problems !!

With a CSR module, even without a USB-CABLE, csr module on a STICK.
But also having problems while executing filecopy's on a USB-stick [the USB stick(s) even got corrupt USB_VID & USB_PID are screwed to 000])


Any Update/Tips/Hints.. on this matter ?

Kind regards
Noel.

Could be some issue with your USB device. I have over 100 9G20 units communicating with cell phone modules over the USB host port without problems.

We finally received our design using the 9G20 and we are not seeing any USB problems. It sure does look like the AT91SAM9G20-EK development boards have a USB Host port issue

Well I was wrong. We do see the same USB problems on our boards as I was seing on the development boards but our boards fail only at temperatures below 0 C where the development board fails at room temperature.

The errors also occur more frequently when I am using the MCI interface to access an SD card.

I think this could be related to bus bandwidth.
The SAM9260 runs at 200 MHz and has a 100 MHz bus.
The SAM9G20 runs at 400 MHz and has a 133 MHz bus.
The SAM9G20 uses much more of the total bandwidth, leaving
less for other peripherals like OHCI and MCI.

If the MCI is running, then the OHCI will get even less bus cycles.

If the OHCI DMA does not get access, it will get underrun errors.

Some tests:

Try running the SAM9G20 at 200 MHz/100 MHz bus.
Check with a bus analyzer if packets are corrupted.

Possible workarounds:
Initialize the bus matrix inside AT91bootstrap with priorities
set to favour the USB OHCI.
Use internal SRAM for OHCI buffers.
This will use another port in the bus matrix, which is normally not used.
The SRAM is fairly limited, and even more so on the SAM9260,
so it it not a good idea to use SRAM on that chip, only on the SAM9G20.

This does not explain temperature variations.

I can't understand: G20 operates in range -40°C to 85°C.
I wonder if You have an Eng Sample CPU.

I can't understand: G20 operates in range -40°C to 85°C.
I wonder if You have an Eng Sample CPU.

I can't understand: G20 operates in range -40°C to 85°C.
I wonder if You have an Eng Sample CPU.

I can't understand: G20 operates in range -40°C to 85°C.
I wonder if You have an Eng Sample CPU.

Has this problem been resolved as we are seeing similar problems using a USB to Ethernet part with the G20?

Has this problem been resolved as we are seeing similar problems using a USB to Ethernet part with the G20?

You need to check for jitter.
The Schematics Checklist for the SAM9G20 has recently been updated,
The VDDPLL should in the new revision be generated by an LDO,
to ensure stability. In previous revisions of the checklist it was connected to the DC/DC converter and apparently this may cause
jitter bad enough to affect the USB.
As far as I know, while the investigation of this has gone one for
some time, is not complete.
Maybe VDDOSC should also be driven by an LDO.

Careful decoupling of the VDDPLL and VDDOSC seems also to be important. Putting the decoupling right below the BGA seems to have improved the situation for the USB *device*. Not sure if this was
because that board had particular bad decoupling or not.