usb cdc buffer overrun problems

richardb · Post by **richardb** » Thu Jul 30, 2009 2:01 pm

Hi, maybe somone can help with a problem i'm having

we have an application that sends data to a pic then forwards it to another then the result is copied back to the usb port, we found that generally we had problems and that the data would be missed or corrupt if we sent to much data in one go.

it turned out that we could simulate the same problem with the code below on the pic18f4550 by using realterm and sending the following in a text file (there are cr and lf added to the ends)
12345678
12345678
12345678
12345678
12345678
12345678
12345678
123

one char less and it works just fine

the code is same as in the sample provided by SF

Code: Select all

/ device and clock...
Device = 18F4550
Clock = 48

// 20Mhz crystal, 48Mhz internal (FS USB)
Config
   PLLDIV = 5,
   CPUDIV = OSC1_PLL2,
   USBDIV = 2,
   FOSC = HSPLL_HS,
   VREGEN = ON
      
// import modules...
Include "usbcdc.bas"

// this event will fire if the DTR line
// from the PC is set or cleared...
Event OnControl()
   Output(PORTD.0)
   PORTD.0 = DTR
End Event

// assign event handler...
CDC.OnControl = OnControl

// main program loop - this just simply reads a byte from a
// terminal window (for example, SerialCommunicator) and then
// echo it back...
While true
   If DataAvailable Then
      WriteByte(ReadByte)
   EndIf
Wend

firstly, is this a bug?
secondly is there any way round this problem at the pic end?
i was hoping i could flag back to the usb that the buffer is full, like flow control over usb
any help would be great

Richard

richardb · Post by **richardb** » Tue Aug 04, 2009 9:48 am

any ideas? or suggestions for a workaround?

Doj · Post by **Doj** » Tue Aug 04, 2009 5:12 pm

I do not wish to sound patronising but how about just sending smaller amounts that do not fail and have more packets if that will get it going right now?

richardb · Post by **richardb** » Wed Aug 05, 2009 8:23 am

the example i gave isnt what we are using at all.
we are actually sending a minimum of 5 bytes per packet and upto 14 bytes per packet.
we found this was ok sending a few commands close together, but any more would cause the pic either to lock up or mostly just generate bad data. we have put delays into the send routine but it severly limits the data rate.

RangerBob · Post by **RangerBob** » Wed Aug 05, 2009 11:14 am

Hello Richard,

Just had a poke through the CDC code for you and noticed the following in USBCDC.bas ;

Code: Select all

Const 
   PriorityLevel = USB_SERVICE_PRIORITY, // ISR priority
   TXBufferSize = 16,  // higher value may cause RS232 apps problems, leave!
   RXBufferSize = 72,  // must always be larger than sizeof(CDCDataRX)
   CDCVarAddress = _RAM_START   // private TX and RX buffer address

This would tie up with your corruption if sending more than 72 bytes as the module side "RXBufferSize" as defined is only 72 bytes wide.

Without testing it myself but looking at the RAM map, *i think* it looks like you could increase this number up to 256 bytes without impacting anything else, as I think the next thing above these buffers at $4B8 is the USB TX/RX Buffer RAM at $600, but all the pointers for this are byte wide so 256 max.

Again I haven't tested any of this any may be talking absolute cobblers, but hopefully it will put you on the right track.

The other option I have thought about is in some way stopping the USB ACK to the PC in some way, as it was envisaged that this would act as a CTS signal in the CDC protocol as the PC would then hold sending until the slave is ready, but I can't think of a good clean way of doing this.

Nathan

richardb · Post by **richardb** » Wed Aug 26, 2009 12:32 pm

thanks Nathan,

i had a quick play with this and it does change the amount of data that can be received in a block, unfortunately the buffer overrun problem still exists.

we've had to pace the data to the pic with quite large delays, which makes the throughput dissapointingly slow.