pic locking up with usb cdc

richardb · Post by **richardb** » Wed Jul 25, 2007 7:55 am

i'm just in the process of tracking down whats going on but this is what i have so far.

i'm running a pic in a loop getting data from an external adc and sending it to the usb with the code below.

Code: Select all

Sub sendtopc(ADC_RESULT1 As Word)
    BNC = 1
    LED = 1
    CDC.WriteByte("s")
    CDC.WriteByte("t")
    CDC.WriteByte(adcclockreg)
    CDC.WriteByte(adcsetupreg)
    CDC.WriteByte(ADC_RESULT1.BYTE1)
    LED = 0
    CDC.WriteByte(ADC_RESULT1.BYTE0)
    CDC.WriteByte(frequency.byte1)
    CDC.WriteByte(frequency.byte0)
    CDC.WriteByte("e")
    BNC = 0
End Sub

if i run it it will loop 1367 times then stop

if i comment out 1 writebyte it will stop after 1538 loops

this is without reading data from the comport at the pc end.

i'm going to try some other tests

as it seemed to restart at one point but i wasnt sure if it was due to opening a terminal or that it just restared

richardb · Post by **richardb** » Wed Jul 25, 2007 8:56 am

ok I've modified it to send 20bytes and now it stops at 615 counts

i've just left it for 20 mins and without doing anything it doesnt restart counting.

if i open a terminal program(realterm) it immediately starts counting even if its set to the wrong commport. it then stops counting again at 1230.

it then restarts if i change to the correct commport, and continues without problems.

is there any way to test at the pic end if im actually connected to a comport?

David Barker · Post by **David Barker** » Wed Jul 25, 2007 4:28 pm

The more bytes you send, less loops - less bytes and you get more loops. Sounds like your PC RX buffer is overflowing - which will lock the PIC when trying to xmit. You probably need to get some flow control - PC sends start char, PIC sends a fixed number of data packets back etc. Alternatively, see if your terminal software asserts DTR. For example,

Code: Select all

device = 18F4550
clock = 48
config
   PLLDIV = 5,
   CPUDIV = OSC1_PLL2,
   USBDIV = 2,
   FOSC = HSPLL_HS,
   VREGEN = ON
include "usbcdc.bas"

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

// main program...
CDC.OnControl = OnControl
output(PORTD.0)
while true
   Write("Hello",13,10)
   delayms(1000)
wend

In the above example, PORTD.0 goes high when hyperterminal connects and goes low when hyperterminal disconnects. You could just use a flag instead. For example,

Code: Select all

event OnControl()
   PortConnected = DTR
end event
...
if PortConnected then
   ...
endif

richardb · Post by **richardb** » Fri Jul 27, 2007 7:04 am

The more bytes you send, less loops -

Yes- that was information for you.

Unfortuantely i was just testing with the terminal progam. It will actually be connecting to a pc that uses a cnc programming language which doesnt seem to support flowcontrol, i will contact them to see if its been left out of the help file but it's normally very comprehensive.

Is it possible to modify the usb routine flag a problem and resume anyway ?

David Barker · Post by **David Barker** » Fri Jul 27, 2007 7:59 am

> Is it possible to modify the usb routine flag a problem
> and resume anyway ?

As I mentioned before, I think it is the PC RX buffer that is getting swamped. You need to look at reducing the transmission rate from the PIC. Try putting a delay in your loop to see if that makes any difference to the number of iterations. Use a large delay to start with and reduce.

You really don't want to be sending any data unless a connection is present. USB CDC is not RS 232. Unless you can have some kind of flow control or know that the connection is always present, you may have ongoing problems.

richardb · Post by **richardb** » Fri Jul 27, 2007 11:11 am

As I mentioned before, I think it is the PC RX buffer that is getting swamped. You need to look at reducing the transmission rate from the PIC. Try putting a delay in your loop to see if that makes any difference to the number of iterations. Use a large delay to start with and reduce.

The average data rate that i'm using is slow which was why i increased the backet size to 20 to reduce the time i had to wait. Its about 5 samples per second so an average of about100bytes/sec.

You really don't want to be sending any data unless a connection is present. USB CDC is not RS 232. Unless you can have some kind of flow control or know that the connection is always present, you may have ongoing problems.

I think you should put this in the help file.

David Barker · Post by **David Barker** » Fri Jul 27, 2007 11:57 am

> The average data rate that i'm using is slow

It's unlikely that the RX buffer is overflowing then. I tried this program connected to hyperterminal

Code: Select all

device = 18F4550
clock = 48
config
   PLLDIV = 5,
   CPUDIV = OSC1_PLL2,
   USBDIV = 2,
   FOSC = HSPLL_HS,
   VREGEN = ON

include "usbcdc.bas"
include "convert.bas"

dim Index as word
dim Count as byte

Index = 0
while Index < 8192 
   Write(HexToStr(Index,4), " : ")
   for Count = 0 to 9 
      Write(HexToStr(Count,2)," ")
   next
   Write(13,10)
   delayms(10)
   inc(Index)      
wend

It seemed to be quite happy handling the data - perhaps you could try the above on your system and see what happens...

richardb · Post by **richardb** » Wed Aug 01, 2007 8:52 am

The pic stops when there was no program to receive the data