cdc usb locks up after a while

[gfbankston]

Hello,

Using PIC18F45K50 and library routines. USB works well for up to 15 minutes or so, then it seems that the PC no longer gets the
usb_cdc_puts(*str) data. We put a debug feature on the lcd on our unit that shows the transmissions to the PC, so we feel confident that it working. It is not going out I guess. I am receiving a TRUE back from the routine.

It almost acts like a buffer full problem. Our 'packet' is only 5 characters.
Transmissions from the PC do not appear to be affected.

Would this be a PC driver problem?

Have there been changes to the USB CDC in CCS recently? I have 5.09

TIA

Glen K4KV

[gfbankston]

I have noticed, now, that I am getting a FALSE from usb_cdc_puts(*str)
when it locks up. Incoming packets are still coming through, but it
will not let me send packets out.

It is acting like there is a single buffer on the rx of the PC, and it is filling up
then not accepting any more data...

I have no idea if I can use the usb_puts() to a specific endpoint, or what
end points might be available.

Or, is there a way to flush or reset the channel?

TIA

Glen K4KV

[guy]

it's probably not the problem but could be that the LCD routines get in the way? There are sometimes time-critical issues when working with LCDs which could mess things up.
Just for fun maybe remove the LCD debugging code and see if it helps?

[Ttelmah]

I think this early V5 version (assuming you mean 5.009), was one that had the problem, that GIE could get disabled when printf was used. After any line where printf is used, add a 'enable_interrupts(GLOBAL)'.

Other things that can cause this are inadequate smoothing on Vusb (this _requires_ a capacitor with good HF performance - 0.47uF polyester is ideal, right by the chip pins). Don't think 'bigger is better' here. A large capacitor like 10uF electrolytic, has worse HF performance, and can lead to problems because it is too big, making this supply take longer to stabilise. Also the minimum capacitor in the data sheet, on some chips is too small. 0.33uF _min_, 8uF _max_.
On some systems adding series resistors in the D+, and D- lines, seems to help reliability (22 to 27R).

5.009, was generally considered pretty much a 'beta' version. V5 had just about started to work OK, but it is possible this is the cause of your problems. This was the first V5 version I actually kept. I still used 4.141, as the more reliable compiler at this point.

[gfbankston]

Hello,

The compiler is actually version 5.026, and the Programmer Control Software is 5.009.

It is weird because the USBDRIVERS shows CurrentVersion = 30-Nov-09 and Local Version = 24-May-11

Anyway, I switched to Microchip's vendor ID and PID for their usb demo code, and it actually loaded the Microchip driver when the unit was plugged in. The Microchip also locked up. The microchip apparently uses Microsoft usbser.sys and I would bet that CCS does as well.

I tried calling usb_cdc_flush_tx_buffer() just before each 4 byte packet is sent, and it also did NOT help. Still locked up around 2K worth of characters as best I can figure.

I would bet it is the CCS usb cdc code that is the problem, but I find it hard to believe no one else has experienced this problem.

Again, the incoming packets are not affected, they still work. If I do receive a packet requesting the data (4 bytes) it still sends it to usb_cdc_puts() and receives a FALSE back. The ONLY cure is to stop the PC application and remove the usb cable from my unit and then re-attach and start the PC app again.

I am ONLY using CCS library calls...

TIA

Glen K4KV

[gfbankston]

I was told by Microchip to use a 1uf low ESR cap. I am using a 1uf but not sure about the ESR rating.

I would have thought that I would also have problems on rx as well.

It is ALMOST repeatable on the failure, around 2K bytes of data sent from the PIC45K50 unit. The reason I say almost is that I do not have the tools (usb sniffer) to tell exactly where the failure is.

I have seen other chips put a 22 ohm in the data lines, but the data sheet did not call for it, so I left them off this design.

[gfbankston]

I use NO delay loops in the software anywhere. Everything is interrupt driven. The same code is also on the usart port in case the user wants to use serial instead of usb, and it does not lock up.

The graphic lcd is somewhat expensive as far as cpu cycles are concerned, but, still, a 32x24 character only takes a few milliseconds to write.

I am not sure how long it would take, not running usb_task(), before the PC disconnects me. I think it could be 100ms or more...
It never disconnects...

If I force a usb_detach() after receiving a FALSE back from usb_cdc_puts() then wait 2 seconds (timer) then usb_attach(), it does NOT fix the problem.

[PCM programmer]

[Ttelmah]

On the 22R resistors, the internal peripheral is right on the bottom of the legal match range, without these. On some PC chipset's this causes problems. Had systems that would run with 90% of computers without them, but on some PC's would repeatedly have glitches. Microchip do recommend them in one of their application notes. The need for them also depends on the 'match' of your tracks on the board. They can help prevent problems if these are not quite right.

I've got a few hundred systems running with the 25K50. Code built with 5.019, about march last year, then upgraded on some systems middle of last year to a version built on 5.026. These run 24/7, logging data to an internal SD card on the PIC, and also sending a simplified copy to an embedded PC over the USB. Some have got over nine months continuous running logged without a single glitch on the USB.

Good ground plane.
Good local suppression round the PIC.
Good smoothing on Vusb.
Legal tracks to the USB connector (you'd be surprised how many machine have illegal track spacing, thickness etc., and how this does affect reliability).
Good supply regulation.
etc.. etc..