MSP430f5529 usb monitor device

USB device engine (SIE) on MCU is not available for bus monitoring, because it is too smart for this purpose. The engine is designed to make the firmware interface (registers) simple. Device engine passes just the transaction of its device address (USBFUNADR registor), and drops all other addresses. When a transaction of its device address comes, the engine actively responds to it. For example, for SETUP transaction, the engine returns ACK packet, driving D+/D-, without firmware intervention.

You may have to apply more primitive parts (USB transceiver) for this purpose.

The outline of pod of typical FS/LS (Full-/Low-Speed) bus analyzers is,

hook to USB line ---> FS/LS tranceiver --- CPLD --- USB-FIFO ---> to PC USB port

CPLD packs the outputs of transceiver, and it sends packed data to PC host over a high-speed USB-FIFO. PC application decodes bus protocol (NRZI, DPLL, bit stuffing, etc.) and high-level protocols (packet - transaction - transfer, class protocol).

Tsuneo

Hi Tsuneo.

Thank you very much for your detailed and professional reply. it is perfectly understood and saves us some barking on the wrong tree (as we say here).

With that said, can you please direct us to the leading components and some design referrences used for such pods (FS/LS transceiver, CPLD and USB FIFOs). I'm sure we can find them, but something tells me you might know a few...

thanks again and best regards,

Amichai

a) FS/LS transceiver
Any chip will do,
TI TUSB2551A, Fairchild USB1T11A, Maxim MAX3455E, ST STUSB02E, Micrel MIC2550/1A, etc.
Just the receiver signals (VP,VM,RCV) is used. The transmitter (/OE) is disabled.

b) CPLD
Any 3.3V CPLD is OK
Xilinx CoolRunner, XA9500XL, Altera MAXII, Lattice, Actel, etc.
The receiver signals are sampled at 48MHz (12MHz, 4x oversampling for DPLL) over one stage synchronizer. When the signals are directly passed to PC, five signal pairs are packed into 15 bits. Packed output with 1 bit padding go to 16 bits USB-FIFO chip. If you decode bus protocol on this CPLD, existing USB PHY design in Verilog (usb_rx_phy.v) is available on OpenCores (free registration is required).

USB 1.1 PHY on OpenCores
http://opencores.org/project,usb_phy

c) High-speed USB-FIFO
Cypress EZ-USB FX2LP (56pin) is often applied. This chip provides 48 MHz clock (CLKOUT) to the CPLD, and its FIFO interface is also synchronized to this clock. FX2LP requires short firmware for this purpose (Slave FIFO mode). Keil eval version and bulk example on EZ-USB_devtools_version_261700.zip is enough for firmware development. This dev tool is downloaded on this Cypress site.
"CY3681 EZ-USB FX2 Development Kit"
http://www.cypress.com/?rID=14319

The coding for Slave FIFO setting is described on this TRM page.
9.3.10 Auto-Mode Example: Synchronous FIFO IN Data Transfers - EZ-USB Technical Reference Manual
http://www.cypress.com/?rID=38232

As of other high-speed USB-FIFO, FTDI FT232H and FT2232H work on 60MHz FIFO clock in synchronous mode. To make 48MHz from this clock out, you need PLL on the CPLD.


Lastly, this page describes USB bus timing well.

USB Made Simple - Part 3: Data Flow
http://www.usbmadesimple.co.uk/ums_3.htm

Tsuneo

Dear Tsuneo,

Again, thanks for a very detailed and professional reply. You have definitely put us on the right tracks.

We do have some experiance with some of the components you detailed (the MAX II from Altera, and FTDI modules) so i believe we will not have too much trouble there.

With that said, in comparison to the EZ-USB FX2LP, the FTDI FT245R looks very much similar in function (also have 48MHz clock) thou it is only 8bit bus (which is not such a problem - is it?  the MAX II will do the HighByte/LowByte alternations) and is much more available to us ( we know the agent here very well)...

What do you think?

Thanks again, and best regards,

Amichai

FT245R works on full-speed (FS).
To carry monitoring result of FS bus in real time (ie. without so large buffer on the pod), the speed of FS USB-FIFO is not enough. The speed of HS USB-FIFO ensures steady transfer without data drop.

Tsuneo

Dear Tsuneo

Real time is not an issue in this project. We have some idle time (>2-3s) between bursts of up to 6kB a burst. so flushing internal pod memory is possible when the monitored line is not active.

That gave me an Idea when i was sleeping on it last night: in order to save serial production costs (which are quite high with the CPLD-->USB FIFO trick - which got high score for elegance thou) we might use high speed MCU such as PIC32 from Microchip or the C2000 series from TI (or even 32 ARM MCU from TI) all running on 80MHz and faster clocks.

My idea is to connect Vp, Vm & Rcv signals from the USB xceiver and record line changes (interrupt for change in any line) coupled with 80MHz timer data snapshot on the internal RAM (or Flash) - so for each change i will be able (between interrupts and when the monitored line is not busy) to calculate the duration (clock ticks) between each change thus decode line status according to the USB spec, and store this status to the RAM, just to be flushed at a lower rate (even via UART or SPI) when the monitored line is not busy (we would have plenty of these). so it all comes out downto:

USB Line --> line isolator (such as ADuM1400) --> USB xceiver --> high speed MCU --> RS232/USB adapter --> host computer running analyzer SW.

true, power consumption needs to be carefully monitored, but todays MCUs (even the high speed large memory ones) consume less than 100mA at their most active state. that's good for me any day. also high memory volume required (for each change i need 3Bytes) but most of these MCUs have 256kB and higher RAMs (+ i can always use external memory chips).

the code should be very simple: main loop to decode buffered data according to the USB spec and flush the FIFO from the RAM down the UART, and an interrupt handler which for any change at any input records the status of each input (total of 3 bits) and the clock snapshot (up to 16 bits)  to the FIFO in the RAM. as simple as that... and who knows, maybe if i use fast enough MCU i would be able to decode the line status inside the interrupt handler so to save RAM (returning to 1 bit/bit decoder ratio).

what do you think?

thanks and best ragrds,

Amichai

How many units do you make?
If it is a couple of units, take an easy way for you ;-)

Anyway, sampled USB line data requires considerable amount of processes to make it meaningful for our eyes. The distribution of processes between the pod and PC is up to you.

Another idea is 60MHz sampling (5x oversampling) instead of 48MHz (4x oversampling). And then, FT232H (FT2232H) is applied directly. Sampled line data is decoded to signaling of 12MHz time base by DPLL, at the front end. It doesn't affect to the rest of processes. The oversampling and DPLL absorbs slight difference of frequency / phase of bit clock between the line and monitoring system.


> USB Line --> line isolator (such as ADuM1400) --> USB xceiver

The order of the isolator is swapped.

USB Line --> USB xceiver --> line isolator (such as ADuM1400)

The differential receiver on the USB transceiver is directly connected to D+/D- line.

Tsuneo

Yup,Tsuneo,

I thank you very much for your professional help. we definitely have some considerations and decision making to do choosing the right way to take.

we will do our homework and play around with some of the development kits to get the best choice.

I will do my best to update you guys on the progress and outcomes.

thanks again, and best regards,

Amichai