Probleme mit der CDC-Geräteklasse

Ich verwende das 16-Bit-28-Pin-Starterboard von Microchip und die USB-Kommunikation mit dem PC bricht ständig ab.

Auf der Platine befinden sich zwei Mikroprozessoren. Der Anwendungsprozessor kommuniziert über UART mit dem USB-Prozessor. Der USB-Prozessor ist als USB-Gerät der CDC-Klasse konfiguriert und wird im Geräte-Manager als serielle Schnittstelle angezeigt.

Das Gerät listet ok auf und die Daten, die vom PC zum Anwendungsprozessor übertragen werden, sind ok. Der Anwendungsprozessor antwortet dem USB-Prozessor, aber die Antwort erreicht nie den PC.

Ich weiß, dass die UART-Kommunikation zwischen den beiden Prozessoren in Ordnung ist, weil ich eine BusBee verwende, um den UART zu überwachen. Ich habe den Code für den USB-Prozessor (der von Microchip kam) nicht geschrieben. Es hat schon einmal funktioniert, aber ich bekomme es anscheinend nicht wieder zum Laufen.

Gibt es ein Tool oder etwas, mit dem ich die USB-Endpunkte auf dem PC debuggen kann?

So etwas wie Wireshark, aber für USB?

Hat jemand anderes das 16-Bit-Starterkit von Microchip verwendet und ähnliche Probleme gehabt?

Antworten (2)

Der PIC UART kann wählerisch sein. Haben Sie daran gedacht, das Frame Overrun (OERR)-Bit zu überprüfen? Der PIC kann keine UART-Kommunikation empfangen, bis der OERR gelöscht ist.

EDIT: Ich dachte auch ... vielleicht könnten Sie eine Art Loopback versuchen? Das heißt, schneiden Sie den UART aus der Schleife, und wenn der PC etwas über USB sendet, senden Sie es einfach direkt zurück. Dies würde Ihnen sagen, ob das Problem bei der UART- oder der USB-Seite des PIC liegt.

Ich habe keine Möglichkeit, das OEER-Bit zu überprüfen oder den USB-Prozessor als Loopback einzurichten, da ich keine Kontrolle über diese Firmware habe. Ich habe bereits den Anwendungsprozessor echoen lassen, was er empfängt, und das funktioniert. Was würde dazu führen, dass das OERR-Bit gesetzt wird? Kann ich es löschen, indem ich den USB-Prozessor zurücksetze?
Das Problem war mit dem UART auf dem USB-Prozessor. Sobald der UART auf dem USB-Prozessor einen Fehler hatte, gab es keine Möglichkeit, ihn zurückzusetzen. Die Lösung bestand darin, das Entwicklungsboard einzuschalten, während der MCLR-Reset für den Anwendungsprozessor gehalten wurde. Lassen Sie dann das MCLR los, nachdem der USB-Prozessor eingeschaltet wurde.

USB-Sniffing :

Windows: http://sourceforge.net/projects/usbsnoop/

Linux: http://www.linux-usb.org/tools.html

Mikrochip-CDC :

Ich fürchte, ich weiß nichts über ihren offiziellen Stack, aber...

Drüben bei http://dangerousprototypes.com haben sie einen neuen Open-Source-PIC-USB- Stack gebaut.

Sie verwenden es im neuen Single-Chip Bus Pirate . Der Bus Pirate CDC-Treiber ist hier .

Oder Sie können die ursprüngliche alternative Stack-Version hier abholen .

Ich habe versucht, USBSnoop zu verwenden, und jedes Mal, wenn ich versuche, den Snooper auf dem Gerät zu installieren, funktioniert das Gerät nicht mehr. Ich kann keine Verbindung mehr zum COM-Anschluss herstellen, sagt eine fehlerhafte COM-Anschluss-ID.
USBsnoop scheint nur mit Geräten der HID-Klasse zu funktionieren. Ich habe stattdessen SniffUSB ( pcausa.com/Utilities/UsbSnoop ) verwendet.