Can Teensy be used to capture USB data from a USB cable ?

Status
Not open for further replies.
E

Elmue

Well-known member
Hello

I would like to use a Teensy 3.2 to capture the data that a computer is sending to a USB printer.

My idea is to connect the Teensy with an adapter cable to the printer's USB cable.

The Teensy would have to listen to all the packets coming in without ever sending data back.

Then I would pre-filter the packets that I'am interested in and send them out via an UART.

Is this possible with Teensy 3.2 ?

Any code samples available ?

If not:
Did anybody hear of a similar project that already exists for this purpose (with other hardware) ?


P.D.
I'am not allowed to install anything on the computer.
So a software capture is not possible.
It must be done with hardware.
 
Last edited:
Hello

I don't know what more information you need.
Getting the data from a USB cable.
That's it.


Yes, I know that there are sniffers like Beagle and that they are expensive.
So they are no solution for me.

But I also saw that people have built a digital oscilloscope with a Teensy which is normally much more expensive.
So why not use a Teensy instead of a Beagle ?


The first question would be if the processor of the Teensy is capable to sniff USB data.
And if yes, the rest would be a question of software.
 
I'm pretty sure the answer is no, or at least "probably not", but maybe....

The USB hardware automatically performs much of the USB protocol. However, you might be able to turn that off with the EPHSHK bit in the endpoint registers. See section 41.5.23 on page 994. Normally that's only done for isochronous endpoints. If you did this for the other ones, maybe you'd get an interrupt for each token and a very different USB stack could reassign the BDT table so you'd capture lots of packets efficiently. Maybe? But whether it works for NAK and other packets is a good question.

How you'd get the data out to another PC is also a small matter to be solved. Total Phase uses a 480 Mbit/sec USB port. You'd have to send over serial or SPI, which might be possible to do efficiently with DMA... but even more tough programming challenges.

There's also the small matter of electrical compatibility. Is the USB port high impedance when receiving? I've never really worried about the impedance and lowest level details (eye diagrams, JK states, bit stuffing, etc).
 
Hello Paul

Thanks for your answer.

I also had doubts if I can tell the processor just to listen and never to answer, but on the other hand give me the data that has been received for a device.
Probably this is not possible.
I have read the MK20DX256 datasheet but the USB stuff is very complex.


I have been searching for many many hours for a project that allows to capture USB.
I found some on Github:

https://github.com/kuruoujou/ECE-337-USB-Data-Sniffer/blob/master/docs/finalReport/finalReport.pdf
https://github.com/openvizsla/ov_ftdi
https://github.com/ultraembedded/cores/tree/master/usb_sniffer

but they use some big chips like FPGA, FTDI, UPLI PHY.

I have the impression that capturing USB is very complicated if you do it on your own and very expensive if you buy a ready solution.

______________________________

> How you'd get the data out to another PC is also a small matter to be solved

I do not need to transfer much data.
If I would have to capture a video stream it surely would be more difficult.
But the printer is receiving a small amount of data (few kilobyte) that can easily be stored in a FIFO in RAM and then sent via SPI or UART to a second Teensy that sends it via USB to the second computer.
 
Last edited:
This is the sort of project where you're only just getting started after you've solved the tough real-time capture hardware.

A tremendous amount of work is needed on the software side to get to something as nice as Total Phase's Data Center software.
 
I think it's vastly faster / easier / cheaper to do this in software on the host computer, rather than external hardware. That's why I was curious about the "not allowed to install anything on host PC" condition. There are a variety of scenarios that might apply to.
 
> faster / easier / cheaper to do this in software

You don't tell me anything new.
But I don't have permission to install anything on that computer.
 
Software-only USB capture usually only works on a single operating system, and it only gives you a view as seen by that host controller. That's great for a lot of fairly common uses, like trying to reverse engineer random but already-working USB devices, or debugging your own device that involves custom descriptors and packets but is built on top of already-working USB hardware and low-level USB stack.

But when you want to test device hardware+firmware with Mac, Linux and Windows, or your own USB host hardware, or a tablet or smartphone acting as USB host, or when you're developing the lower-level device code and especially if developing the USB hardware, you really want to use a second computer to capture the packets. Especially if you're developing a USB host, you need external capture. Consistent software (like Total Phase's Data Center) that runs on a dedicated machine is also a real advantage when you're testing between several different systems.

Hardware capture gives extremely accurate timestamps on all packets. Most analyzers can also capture digital signals (as a simple logic analyzer) with highly accurate timing. Usually you can't get 20 ns timing precision from software capture, and well sync'd capture of non-USB signals isn't an option at all.

While these special cases aren't as common as reverse engineering devices and customizing a device on top of a solid USB stack, they do exist. A hardware-based analyzer and dedicated computer to capture packets really is needed in some circumstances. Sometime when it's not absolutely necessary, it's still much easier than trying to deal with the limitations of software-based capture.
 
Status
Not open for further replies.
Back
Top