search

ataradov / usb-sniffer

Low-cost LS/FS/HS USB sniffer with Wireshark interface
BSD 3-Clause "New" or "Revised" License
774 stars 85 forks source link

capture trigger: 'disabled' (default), 'low', 'high', 'falling' or 'rising' #39

Open blueoce opened 5 days ago

blueoce commented 5 days ago

It feels akin to utilizing an external triggering function, similar to the level triggering feature in a logic analyzer.How do I use it?

ataradov commented 5 days ago

The trigger is really only useful when you are debugging your own devices. In that case you can set up a GPIO pin to toggle at the interesting parts of the firmware flow. This way you can either capture just an interesting sequence of frames out of a long run time.

Or in the simplest case you can just log level transition on the trigger input. This way you can mark events in the firmware and have them related to the frames on the line. Those events will be timestamped the same way as the regular packets. So, you can set a GPIO when you submit a request to send the data and then time how long it took from the request to the packet appearing on the line.

blueoce commented 4 days ago

Which GPIOs can be configured for external triggering with a sniffer, and after setting up external triggering, how do I choose which GPIO to use for capturing external events? Could you provide an example or suggest where I might find relevant materials?

ataradov commented 4 days ago

GPIOs on the device you are debugging when you develop your own firmware. It depends entirely on your target hardware.

From the sniffer point of view you have two pins - ground and the trigger input. By default there is a pull-up on the trigger input. You can start the capture and short the two pins - you will see messages in the log corresponding to the edge transitions.

If you set it to 'low', then the capture would only happen while you are shorting the pins. If you set it to 'high', then the capture would be paused while you are shorting the pins. If you set it to 'falling', then the capture would start as soon as you short the pins and will continue indefinitely.

Manual shorting is not that useful, obviously. But you can connect the ground to the target ground (there is already a connection over the target USB ground, but more direct connection would not hurt). And the trigger input could be connected to some GPIO pin on the target device. Now when you toggle that GPIO on the target device, you will see timestamped entries in the log.

All of this applies if you are developing your own firmware and not just looking at existing devices.

blueoce commented 4 days ago

To enable external triggering functionality, do I need to write my own firmware, as it's not supported by the existing sniffer firmware? Would modifying just the FPGA code suffice?

ataradov commented 4 days ago

No, I'm talking about your firmware on your USB MCU. It has nothing to do with the sniffer. The sniffer functionality is all there. I described how you can test it without any external hardware by simply shorting the trigger pins.

This sniffer is primarily a development tool. It is meant for people making their own USB devices.

blueoce commented 4 days ago

the IO_IN pin on the FPGA is typically internally pulled up, meaning i woin't see an external pull-up resistor on the circuit board.

ataradov commented 4 days ago

Yes, IO_IN uses FPGA pull-up resistor. When nothing is connected, it has a high level. This is why when you short it to ground, the level becomes low and you see a corresponding message in the capture log.