CCS USB CDC Firmware-Driver Problem

[atoscape]

I use the PIC18F4550 with CCS USB CDC Firmware-drivers to communicate to a host application via CDC (Virtual Comport). I had to make use of a virtual comport since the existing host software only support COM ports and I don't have access to the source to implement clean USB communications.

The host application will send a few request to the device and the device respond to the request with a message (The host application receives the responses without a problem). The host then closes the COM port, wait for about 10 seconds and open the COM port again. It then sends different requests to the device and again the device respond to the request with a message BUT this time the host software does not see the response.

I used Snoopy to debug the USB communications, At both times the COM port is opened the requests and responses are visible. When I debug the Virtual COM port with some serial port monitor, the 1st time a can see the requests from the host and the responses from the device BUT the second time I can only see the requests from the host.

At first I thought it might be a problem with usbser.sys (And it might still be). I then tried to use a custom driver from Thesycon but the Tesycon driver can't even communicate with the device (Although the device is enumerated at the host - device manager).

I then took the same USB descriptors and implemented it on a Silabs C8051F321. The Silabs device works with both the usbser.sys and the Thesycon driver. This makes me think that there might be a problem with the CCS USB CDC Firmware-Driver.

Testing the device with our own host software and emulating the scenario generated by the actual host software the device works fine with usbser.sys (Keeping in mind that the host still won't work with the Thesycon drivers).

Please give me some advice on this problem.

[kimladha]

I have not yet tried to debug the device as throughly but I can confirm that the CCS cdc firmware suddenly stops working intermittently (after a random interval). I used their own example and found that if I modified it to send data continuously then the putc() function failed. You have to use puts().

If I disabled and reenabled the isr (and checked that it had not been triggered) like this:

disable_interrupts(global);disable_interrupts(int_usb);
delay_ms(1);
enable_interrupts(global);enable_interrupts(int_usb);
if(usbif){usb_isr();usbif=0;} // sw interrupt

Then the code stops sending data out again- despite what they say in the notes about the isr.

What I want to know is when they plan to fix it? The C18 one works fine and I have been using this with no problems.... Hmmmm, I wonder if I will renew my maintenance this year?

Regards
Karim

[Ttelmah]

It may not be the CCS code...
I had the same problem, on a board with a VIA chipset. However on Intel based boards, the code ran without a hitch. _Backdating_ the VIA drivers, got it working again...
I was able to repeat this on five different VIA boards.

Best Wishes

[jb2009]

Hi,
I am using the CDC driver to communicate between my PC an my 18F4550 PIC and sometimes (randomly), my program which runs on the PC does not receive all the characters it expects...
It seems that these characters are lost. I am sure the bug is not in the PC program I wrote (it is written with the RS232 API in Labwindows CVI and i can very precisely inspect what i receive on the COM port), so I am suspicious about the CDC firmware delivered by CCS along with the compiler...
Has someone already got a reply or a mean to solve this strange problem ?

[Ttelmah]

I'd suggest starting by putting a USB packet sniffer on a system. Set it to just monitor the packets to the CCS based device, and log them. Then let the system run, till some data has been lost, and look at the packets to see what Windows actually 'saw'. There are a number of 'caveats' about USB serial handling, that do not apply to normal serial transactions. Whatever baud rate the USB device is 'set to', makes no difference at all to the actual transfers. It is just sent as a 'configuration' packet to the USB device, which tells it what to set it's external interface 'to', but can be completely ignored. It is quite possible to have a situation, where another USB device 'hogs' the bus for a while, and if buffers in the transmitting device, are not large enough, then data _will_ be lost, but also, if the buffers are large enough, and the bus then becomes available again, the waiting data can arrive at speeds of several hundred KBaud, which some programs which work fine with ordinary serial interfaces, can then have problems with...
So, do some monitoring, and see if data really is being lost in the USB transactions, then look carefully at the timing of packets either side of the lost data, to see if their might be an overload problem with delayed data.

Best Wishes

[Ramey]

I've built the following aps to work with the PIC18F2455 seriies based on CCS examples.

Two different Keyboard HID implementations (low speed and full speed)
A usb boot loader application based on the ex_usb_serial

All of these work very well with no problems at all.

Now I'm want to make another application almost idential to the previous boot loader. The only difference is that I'm now running usb low speed in this boot loader while before I was run at full speed.

Things start out well and information is passed and acknowledged to and from the PIC. I verify this by running Device Monitoring Studio (very nice program www.hhdsoftware.com

Then all of sudden the PIC "hangs". usb_kbhit allways returns false. By placing a trap in the global interrupt handler I can verify that there aren't any interrupts being called.

So my question is: Has anyone verified that the ex_usb_serial examples function when using low speed USB. Note that a simple character transmission probably wouldn't show this problem.

Any help would be appreciated

Robert Ramey


Below is the trace from Device monitoring studio showing where it hangs. The 06 is the ack from the pic when good record is recieved.

[Ramey]

When I break into the executable after it hangs and check the INTCON register I find 0xc2 (1100 0010). The last bit suggests that its not responding to interrupts because they havent' been cleared.

also my attention is drawn to the following error message when I compile

>>> Warning 216 "usb_loader.c" Line 331(0,1): Interrupts disabled during call to prevent re-entrancy: (usb_token_reset)
>>> Warning 216 "usb_loader.c" Line 331(0,1): Interrupts disabled during call to prevent re-entrancy: (usb_flush_out)
>>> Warning 216 "usb_loader.c" Line 331(0,1): Interrupts disabled during call to prevent re-entrancy: (usb_cdc_flush_out_buffer)


which up until now I've presumed was benign

Robert Ramey

[Ttelmah]

The 'warning' is benign. All it implies is that the response to the interrupt will be _delayed_ till the routine finishes.
Check the errata sheets for your chip. I have a 'memory', of there being an erratum for low speed USB, which chould result in the interrupt not being cleared, and required a little code 'tweak' to fix it.

Best Wishes