Open diggit opened 1 year ago
Does this happen every capture, or do you get some that work?
Do you use the most recent firmware? There was update in the most version where I wait for SE0 after the capture start. This would find the end of the packet if the capture was started in the middle.
Generally there is no way to analyze the data as it gets captured, there is not enough time for that. The only way to do this is to capture the buffer, then process it. This assumes the capture started at the beginning of the packet.
How do you use the trigger? The best way is to connect it to the device under test and in the firmware detect the condition when the traffic is about to start and set the trigger there. This way you will be starting before there is a lot of traffic. Manual triggering is essentially equivalent to the manual start without a trigger.
I was not able to get a single sync with bus heavily loaded with Bulk IN data packets (CDC ACM, 6~18 bytes in size). Used compiled binary linked in readme: https://github.com/ataradov/usb-sniffer-lite/blob/main/bin/UsbSnifferLite.uf2 Trigger was just a simple button. There is no simple way of triggering just before bus gets loaded.
Was it the most recent version of the file? It was updated multiple times and only the latest version contains sync improvements.
This behavior with the latest version is unexpected. I would debug it a bit. Capture D+/D- and GPIO18 (trigger) and GPIO12 (start). Trigger the scope on the GPIO12. You should see your trigger condition some time before the start. If trigger falls in the middle of the packet, then the start should follow right after the packet.
Otherwise the next option is to build the full version of the sniffer. PR2040 is powerful, but there are still limits and it can't constantly monitor the bus.
Hi Diggit, did you use two completely separate busses? Even better use two PCs. One for the USB under test and the other to control the sniffer.
I developed USB devices since 1996. It often makes a difference to use two PCs, even with professional Analyzers.
Dieter :-)
Hi, I have to say, this is really handy tool for USB FS debugging! It already helped me to analyze some issues and improve bandwidth of device I am working on. Now, I am trying to capture high load conditions. Unfortunately, I get:
I read though #4 and understood, that synchronization is problematic under load. In my case, I have to open connection and then provide some data to load the bus. When I start capture and then open connection, packet buffer fills up before I manage to push some data.
Using trigger does not help, because it synchronizes on trigger.
Would it be possible to synchronize on start (s) and stay synced until capture is triggered? Trigger input would serve only as a trigger for capture (storing into memory)