EEVblog Electronics Community Forum

Electronics => Projects, Designs, and Technical Stuff => Topic started by: zzattack on November 01, 2019, 10:22:46 pm

Title: Sniffing USB LS/FS with microcontroller only
Post by: zzattack on November 01, 2019, 10:22:46 pm
I'm looking to do some hardware-based sniffing of communication between a USB 1.1 device and a host not under my control. There's a fair bit of info out there (openviszla, ultraembedded, lambdaconcept) when it comes to elaborate solutions involving FPGAs and possibly fast external memories for buffering USB HS data. That far exceeds my needs, so I'm looking for some advice for the path of least resistance.

It seems there's generally 2 approaches: using a USB PHY in non-driving mode which will unburden me from low level stuff like bit-stuffing and NRZI encoding. The alternative is to operate directly on the D+/D- signals. If possible I would implement this with only a microcontroller. For simplicitly the USB PHY seems preferable. It seems that all current USB PHY's support 480Mbps USB HS which is not necessarily beneficial to me. Such devices are clocked at 60MHz with an 8-bit databus (ULPI, i.e. USB3300) and there's also 16-bit versions implementing the UTMI interface which can run at 30MHz. I wonder if dealing with such a 60/30MHz bus will be problematic. Will I be able to sample and transmit data using a DMA transfer clocked by the PHY? Will I be able to react in time to changes on NXT, DIR and STP pins?

Another idea seems to be to use i.e. a STM32F405 with an external PHY, although I believe this only supports device, host and OTG roles. I just want the microcontroller to be a passive entity monitoring the data, remaining minimally stateful. This approach doesn't seem helpful, but perhaps I'm overlooking things here.

Any tips for either approach are welcomed.
Title: Re: Sniffing USB LS/FS with microcontroller only
Post by: ataradov on November 01, 2019, 10:35:45 pm
There is no way a generic MCU can deal with ULP without having a direct support. And microcontrollers with USB peripheral will hide a lot of details and are not really useful as a sniffer.

FPGA is realistically the only way to go for FS and HS modes. LS mode you may be able to decode on the MCU by sampling D+/D-, but it will still require quite a bit of engineering.
Title: Re: Sniffing USB LS/FS with microcontroller only
Post by: jhpadjustable on November 02, 2019, 12:17:54 am
sigrok + EZ-USB FX2 + fx2lafw might be a good choice for passive monitoring up to FS.
Title: Re: Sniffing USB LS/FS with microcontroller only
Post by: bson on November 02, 2019, 06:23:39 pm
I don't think it's possible to passively monitor USB by just clipping onto it; the reason being you don't know who's pulling D+/D- up/down, or who is doing the talking.  So you really need a pass-through analyzer, and this is far more complicated.  If you're looking to debug USB traffic for your projects, then go buy an analyzer as it's a significant project in itself to make one.  You really also need fairly complete protocol decoding of descriptors and commands for it to be of much use.

I have a LeCroy Mercury t2 which handles my USB 2 needs well; I use it for pretty much every project with USB for a once-over even if it seemingly works flawlessly - the analyzer often reveals minor snags and oddities, like inexplicable retries or bus resets during enumeration that are purely timing related.  (It can highlight transactions that violate the timing specs, which is VERY nice as I can't be bothered to rote memorize them.)

Also, basic device class decoding is suuuper nice.
Title: Re: Sniffing USB LS/FS with microcontroller only
Post by: ataradov on November 02, 2019, 06:28:26 pm
I don't think it's possible to passively monitor USB by just clipping onto it; the reason being you don't know who's pulling D+/D- up/down, or who is doing the talking.  So you really need a pass-through analyzer, and this is far more complicated.
Normal USB sniffers also just listen on the bus. You don't need to differentiate who is talking on the electrical level. Each packet has a synchronization sequence, you just look for those and receive the data.  It is up to the software or a person to know what that data means and infer who would be sending it at this time.