I'm battling a problem with reset on a custom AT91SAM9M10-based board with the USB Device port. Here's what I know:

o Half of our boards come up (i.e. boot linux) without the USB device port responding to the USB at all. No transactions reported on the USB bus analyzer.
o If I explicitly pull nreset to ground a second time, the USB device port starts working.
o We had this problem on an earlier prototype run, but replacing the processor chip (which we did to do an unrelated mod to the board) fixed the problem. We checked the date code and mask rev on the original and replaced processors, and the mask rev is identical, and the date code is either identical or off by a week.
o I've tried messing with the power up order of the different supplies, to no avail. I've also tried manually holding nreset low for a long time (seconds) to eliminate any supply stability problems, and it still doesn't work, unless you release nreset and then pull it low, then release it again, then the USB works.
o As far as linux is concerned, it thinks the port us working.

Any ideas? We're running out of things to try.

- Pete

Hi Pete,

we have the same problem on a custom board based on AT91SAM9G45 (Windows CE 6.0 R3). We have the issue on 3 out of 14 boards. We tried to connect with SAMBA and the connection occurs on warm reset. Did you try with SAMBA?

If you have news about it, let me know. We have contacted service support of ATMEL. We will inform you.

Regards,

Jerome

Hi Pete,

I found the solution. It's a problem on the AT91SAM9.

I think this problem is related to the following errata:

49.2.8.1 UHPHS/UDPHS: USB Does Not Start after Power-up
The USB may not start properly at first use after power-up.
If the device boots out of the internal ROM, SAM-BA boot will not be functional.

Problem Fix/Workaround
There are two possible workarounds.
1. Apply a hardware reset (NRST) after power-up.
Or:
2. Activate the PLLUTMI twice, following the procedure below:
a. Start The UTMI PLL an wait for the PLL lock bit
b. Disable the UTMI PLL and wait 10 μ seconds minimum
c. Restart the UTMIPLL and wait for the PLL Lock bit
Warning: When booting out of the internal ROM, this workaround is not implemented and therefore SAM-BA boot will not be functional.

Below is a possible implementation of the workaround:
/* First enable the UTMI PLL */
AT91C_BASE_PMC->CKGR_UCKR |= (AT91C_CKGR_UCKR_PLLCOUNT & (0x3 << 20)) | AT91C_CKGR_UCKR_UPLLEN;
tmp =0;
while (((AT91C_BASE_PMC->PMC_SR & AT91C_PMC_SR_LOCKU) == 0) && (tmp++ < DELAY));
/* Disable the PLLUTMI and wait 10μs min*/
AT91C_BASE_PMC->CKGR_UCKR &= ~AT91C_CKGR_UCKR_UPLLEN;
tmp = 0;
while(tmp++ < DELAY2); // DELAY2 must be defined to fit the 10 μs min;
/* Re- enable the UTMI PLL and wait for the PLL lock status*/
AT91C_BASE_PMC->CKGR_UCKR |= (AT91C_CKGR_UCKR_PLLCOUNT & (0x3 << 20)) | AT91C_CKGR_UCKR_UPLLEN;
tmp =0;
while (((AT91C_BASE_PMC->PMC_SR & AT91C_PMC_SR_LOCKU) == 0) && (tmp++ < DELAY));

It is documented in the latest version of the SAM9G45.
So nothing can be done for SAM-BA but for their final application, the workaround has to be followed

Regards,

Jerome