somehdlguy
commented
5 years ago This partly gets into "what OV is intended for vs what it isn't intended for". We originally built it for debugging these very low level issues, for which there previously was no open-source tools. It can certainly be extended for other use cases, but we didn't design the gateware with them in mind.
That said, I this is relatively straightforward to do, but would require changing the initialization process to add a filter setup step. The simplest mechanism would be to add a 16 bit vector that enables or disables capturing that PID.
For counter tracking, I'll think about it. The most straightfoward way would be to extend the timestamp field - but that would increase the capture bandwidth for small packet captures. Another alternative would be to stuff a frame on roll-over if no frame had been sent (~4hz).
I think the technically best solution would be to send an extended timestamp field on any that has a 24bit counter rollover from a previous packet. This has the same downsides as stuffed roll-over frames, but doesn't require a constant stream of information to the host.
This of course changes the packet/wire format (which takes us to the discussion in #30 ).
desowin
norbertthiel
laf0rge
matwey
When debugging USB issues in embedded devices, the importance of very low-level details (SOF and NAKs) lowers as the USB stack implementation improves. Once the low-level issues are solved, user focus shifts more into higher protocol layers. This is where Wireshark dissection engine is invaluable. Unfortunately the captures are growing very rapidly and thus the dissection is taking a lot of memory. For example, the capture attached to Wireshark bugzilla https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15908#c6 that contains data captured in less than 12 seconds contains over 1 million packets which require 18 MiB to store in pcap file. The same capture, but on the OS USB URB level (capture contains the payload with very little capture metadata) is merely 9 KiB. The captures are quickly growing to a point where Wireshark dissection engine starts slowing down significantly.
The solution to the capture files growing a lot is to make it possible to filter the low-level data that are of little interest to the user. In my opinion it would be best to implement such filtering in the FPGA gateware itself. The filtering would have a really big impact on reducing the analysis computer CPU uage. Of course, the filtering must be configurable by the user as issues like https://github.com/ARMmbed/mbed-os/pull/11103 are not possible to be detected when the "filter NAKed transactions" option is enabled.
Besides the actual filtering, we would need some time synchronization mechanism to indicate the 24-bit clock counter overflows when the SOFs are filtered, so the host software can track the realtive time with the accuracy of the 60 MHz clock.