On Tue, Aug 20, 2013 at 5:15 AM, Andreas Naumann dev@andin.de wrote:
Hi Roger,
What are the symptoms you see when this issue triggers?
The symptoms are erroneous USB transaction, seen with a USB port analyzer. These only sometimes (not always) stall the USB communication, e.g. a USB mass storage device cant be read any longer.
What is the test case to trigger the error? Is it just running any USB I/O for long enough time?
Our scenario to reproduce was rebooting a warmed up board (either let it run for >5min or heat up in climate chamber).
However, the beagle probably uses a 26 MHz crystal oscillator (our board uses 19.2MHz), so the PLL5 dividers may be set in a way that the problem never occurs.
The xM uses a 26Mhz, but the errata still applies, as a number of customer boards do show the issue..
http://www.ti.com/lit/er/sprz319e/sprz319e.pdf page 113
I have a beagle-xm (DM3730 ES1.2) with me and would like to reproduce the error.
Roger, this only seems to effect a small number of xM's, as it seems to vary on pll drift. So if your xM is fine, i do have a spare xM C, that pretty reliably shows the issue after transferring a large amount of data over the usb port... I had traded a good xM with a customer such that i could keep re-basing our out of tree dpll5 tweak..
Regards,