Some additional info:
Do you have a proprietary board or an EASY50712 evaluation board?
We have both and on the EASY board we do not see any errors any more. On
the proprietary board we encounter some at high rates, that's why I
believe it is a matter of traces routing.
Eventually the USB I/F is the most high bit rate of all, therefore
routing of its differential signals must be done very carefully.
Spyros
On 23/3/2012 5:11 μμ, Spyridon Tompros wrote:
Yes, I have the same impression about the errors. We need to test
again in detail all speed modes to get a better overview, but the
system works fine. If there is a higher layer protocol that supports
flow control then this bit error rate is practically nothing.
Spyros
On 23/3/2012 4:07 μμ, Conor O'Gorman wrote:
On Fri, 2012-03-23 at 15:41 +0100, Spyridon Tompros wrote:
Hi,
We tested the code on our board. Now the USB host controller
functionality works almost perfect, with some losses at very high rates
(921600), while it does not crash any more nor with use-to-serial
USB or
other media devices.
Thanks a lot,
Spyros
Good to hear, I spent a couple of days tracing the behaviour, and was
happy to find it to be a one line fix. That in-appropriate
halt_channel() call was causing cross-connecting references as I recall.
I also still see some errors, but it seems to recover from them. I
assumed they are due to random glitches/errors on the hardware lines.
Conor
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Best Regards,
Spyridon Tompros
----------------------------------------
Dr. Ing. Spyridon Tompros
36 GE Lebon, 1160 Brussels
tel:+322.5133076
www.qualtek.eu
----------------------------------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
