5
\$\begingroup\$

I'm using the Microchip 16-bit 28-pin starter board and the USB communication with the PC keeps breaking.

There are two microprocessors on the board. The application processor communicates to the USB processor via UART. The USB processor is configured as a CDC class USB device and shows up in device manager as a serial port.

The device enumerates ok and the data being transmitted from the PC to the application processor ok. The application processor is responding to the USB processor, but the response never gets to the PC.

I know the UART communications between the two processors is working ok because I'm using a BusBee to monitor the UART. I did not write the code for the USB processor (that came from Microchip). It's worked before, but I can't seem to get it working again.

Is there a tool or anything I can use to debug the USB end points on the PC?

Something like wireshark, but for USB?

Has anyone else used the 16-bit starter kit from Microchip and had similar problems?

\$\endgroup\$

2 Answers 2

Reset to default
4
\$\begingroup\$

The PIC UART can be picky. Did you remember to check the Frame Overrun (OERR) bit? The PIC will be unable to receive UART communications until the OERR is cleared.

EDIT: I was also thinking...perhaps you could try a sort of loopback? That is, cut the UART out of the loop, and when the PC sends anything over USB, just send it straight back. This would tell you whether the issue is with the UART or the USB side of the PIC.

\$\endgroup\$
2
  • \$\begingroup\$ There is no way for me to check the OEER bit or setup the USB Processor as a loopback since I don't have control of that firmware. I already have the application processor echo what it receives and that is working. What would cause the OERR bit to get set? Can I clear it by resetting the USB processor? \$\endgroup\$
    – mjh2007
    Commented Oct 14, 2010 at 15:54
  • \$\begingroup\$ The problem was with the UART on the USB processor. Once the UART on the USB processor had an error there was no way to reset it. The solution was to power-up the development board while holding the MCLR reset for the application processor. Then releasing the MCLR after the USB processor powered up. \$\endgroup\$
    – mjh2007
    Commented Oct 14, 2010 at 17:04
3
\$\begingroup\$

USB Sniffing:

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

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

Microchip CDC:

I'm afraid that I know nothing about their official stack, but...

Over at http://dangerousprototypes.com they've been building a new Open Source PIC USB stack.

They're using it in the new single chip Bus Pirate. The Bus Pirate CDC driver is here.

Or, you can pick up the original alternative stack version here.

\$\endgroup\$
2
  • \$\begingroup\$ I tried using USBSnoop and every time I try to install the snooper on the device the device stops working. I can no longer connect to the COM port says bad COM port Id. \$\endgroup\$
    – mjh2007
    Commented Oct 14, 2010 at 14:51
  • 1
    \$\begingroup\$ USBsnoop seems to work with HID class devices only. I used SniffUSB (pcausa.com/Utilities/UsbSnoop) instead. \$\endgroup\$
    – mjh2007
    Commented Oct 14, 2010 at 15:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.