OK. This explains the behavior. But it does not explain why a message is duplicated. We can fix the symptom by checking data toggling, but I'd very much prefer to find the cause for the duplicate.
You mentioned that there were data errors in the duplicates. What's the structure of these errors? Bit errors? A skipped or duplicate bit shifting all other bits around?
A duplicate means that the driver has received a packet, but failed to get an ACK out to the host or the host did not receive the ACK correctly. Since ACKs are sent within the same interrupt as the data is received, a conflict with a different interrupt or code which disables interrupts is unlikely.
A scope capture might be enlightening. You could generate a trigger from the main code when you see the duplicate.
working nicely on my laptop, but fail on my PC?
I'll try to do the job
I'll be free these days.
My Logical Anaylizer is 2K in storage deepth.
Is it enought?
I'll make a signal to tell my anaylizer to start when I detect a failure.
My Logical Anaylizer is 2K in storage deepth.
Is it enought?
I'll make a signal to tell my anaylizer to start when I detect a failure.
Got it
http://www.simonqian.com/download/temp/USBD-.zla
The software can be downloaded at:
http://www.embedtools.com/download/downs.asp?ID=1842
trig is the signal I raise to indicate the error, on the fall edge, my analizer start working
usb is USB D- signal, sampled at the frequency 20M
I compile the code with WinAVR 20080430, another error appears:
when PC receiving data, it will sometime stop for about 10 seconds.
IN package is not correctly replied, I think.
The software can be downloaded at:
http://www.embedtools.com/download/downs.asp?ID=1842
trig is the signal I raise to indicate the error, on the fall edge, my analizer start working
usb is USB D- signal, sampled at the frequency 20M
I compile the code with WinAVR 20080430, another error appears:
when PC receiving data, it will sometime stop for about 10 seconds.
IN package is not correctly replied, I think.
I remove other USB devices, and do the test.
It never stops when sending data to PC.
new logged USB data:
http://www.SimonQian.com/download/temp/USB.zla
It never stops when sending data to PC.
new logged USB data:
http://www.SimonQian.com/download/temp/USB.zla
Sorry for the delay, I was (and still am) busy with other projects.
I finally had the time to look at the data you set up for download. There's one full packet visible before the trigger point. And I can see that your logic analyzer is capable of recording more than 1 millisecond worth of data at this resolution. That would be up to 10 packets.
Can you please adjust the trigger so that you record everything leading up to the trigger, nothing past the trigger point? Since the trigger is raised when the error is detected, the problem must have been before it.
Thanks in advance!
I finally had the time to look at the data you set up for download. There's one full packet visible before the trigger point. And I can see that your logic analyzer is capable of recording more than 1 millisecond worth of data at this resolution. That would be up to 10 packets.
Can you please adjust the trigger so that you record everything leading up to the trigger, nothing past the trigger point? Since the trigger is raised when the error is detected, the problem must have been before it.
Thanks in advance!
Thanks a lot for this capture! We are lucky and it contains the point of error!
It seems it's a bug / transmission error on the host side. The LA capture clearly shows that we send an ACK and the host does not react to it. That's what data toggling is good for, after all.
Here's the decoded capture. The first column is the time in microseconds, the second consists of the data bytes we decoded and the third is the trigger signal.
So it's obvious that we must check for correct data toggling to be sufficiently USB compliant. Can you please send me a summary of your changes by e-mail? I'd like to add them to the next version of the driver or at least add hooks so that users can check for data toggling.
It seems it's a bug / transmission error on the host side. The LA capture clearly shows that we send an ACK and the host does not react to it. That's what data toggling is good for, after all.
Here's the decoded capture. The first column is the time in microseconds, the second consists of the data bytes we decoded and the third is the trigger signal.
Code: Select all
9.700 e1 1 <--- OUT
15.000 01 1
20.300 c1 1
--------------
--------------
37.000 c3 1 <--- DATA0
42.400 ef 1
47.700 01 1
53.100 00 1
58.400 00 1
63.700 00 1
69.100 00 1
74.400 00 1
79.700 00 1
85.100 e0 1
90.400 e1 1
--------------
--------------
106.500 5a 1 <--- NAK
--------------
--------------
124.500 e1 1 <--- OUT
129.800 01 1
135.100 c1 1
--------------
--------------
151.800 c3 1 <--- DATA0
157.200 ef 1
162.500 01 1
167.900 00 1
173.200 00 1
178.500 00 1
183.900 00 1
189.200 00 1
194.500 00 1
199.900 e0 1
205.200 e1 1
--------------
--------------
221.200 5a 1 <--- NAK
--------------
--------------
239.300 e1 1 <--- OUT
244.600 01 1
249.900 c1 1
--------------
--------------
266.600 c3 1 <--- DATA0
272.000 ef 1
277.300 01 1
282.700 00 1
288.000 00 1
293.300 00 1
298.700 00 1
304.000 00 1
309.300 00 1
314.700 e0 1
320.000 e1 1
--------------
--------------
337.200 d2 1 <--- ACK [NOT HONORED BY HOST]
--------------
--------------
357.900 e1 1 <--- OUT
363.200 01 1
368.500 c1 1
--------------
--------------
385.300 c3 1 <--- DATA0
390.600 ef 1
396.000 01 1
401.300 00 1
406.600 00 1
412.000 00 1
417.300 00 1
422.600 00 1
428.000 00 1
433.300 e0 1
438.600 e1 1
--------------
--------------
454.800 5a 1 <--- NAK
--------------
--------------
472.900 e1 1 <--- OUT
478.200 01 1
483.500 c1 1
--------------
--------------
500.300 c3 1 <--- DATA0
505.600 ef 1
511.000 01 1
516.300 00 1
521.600 00 1
526.900 00 1
532.300 00 1
537.600 00 1
542.900 00 1
548.300 e0 1
553.600 e1 1
--------------
--------------
569.700 5a 1 <--- NAK
--------------
--------------
587.700 e1 1 <--- OUT
593.000 01 1
598.300 c1 1
--------------
--------------
615.100 c3 1 <--- DATA0
620.400 ef 1
625.800 01 1
631.100 00 1
636.400 00 1
641.800 00 1
647.100 00 1
652.400 00 1
657.700 00 1
663.100 e0 1
668.400 e1 1
--------------
--------------
684.400 5a 1 <--- NAK
--------------
--------------
702.500 e1 1 <--- OUT
707.800 01 1
713.100 c1 1
--------------
--------------
729.900 c3 1 <--- DATA0
735.200 ef 1
740.600 01 1
745.900 00 1
751.200 00 1
756.600 00 1
761.900 00 1
767.200 00 1
772.600 00 1
777.900 e0 1
783.200 e1 1
--------------
--------------
800.500 d2 1 <--- ACK
--------------
--------------
818.800 e1 1 <--- OUT
824.100 01 1
829.400 c1 1
--------------
--------------
846.200 4b 1 <--- DATA1
851.500 00 1
856.900 00 1
862.200 00 1
867.500 00 1
872.900 00 1
878.200 00 1
883.500 00 1
888.900 00 1
894.200 3f 1
899.500 e9 1
--------------
--------------
915.700 5a 1 <--- NAK
--------------
--------------
So it's obvious that we must check for correct data toggling to be sufficiently USB compliant. Can you please send me a summary of your changes by e-mail? I'd like to add them to the next version of the driver or at least add hooks so that users can check for data toggling.