USBCDC - VCOM Failure

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

USBCDC - VCOM Failure

408 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by cmcquaid on Sat Mar 10 12:44:25 MST 2012
If anyone out there is using USBCDC, could you look at D+ or D- and tell me if you see something funny?

I would expect to see traffic in short bursts, once per millisecond, but I see almost constant activity. If I turn on an LED during CDC_BulkIn, I can see it gets called almost continuously. Curiously, other examples based on the same stack are well-behaved.

I have almost given up on getting USBCDC to work on the LPC1343. It does work for me, but only up to a point. I need to report 3 signed bytes at 100Hz and the best solution I have runs for 30 seconds or so, then hangs for a few minutes before repeating the cycle.

I've tried starting from several different examples. I've tried them unmodified. I've used proper buffering, throttling based on SOF, inserting Zero Length Packets. I've also tried using an LPC1769 instead. I've tested on XP and Windows7-64bit.

This is a pro-bono project, so I'm inclined to take the easy way out and use something that 'just works'.
0 Kudos
2 Replies

390 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by cmcquaid on Mon Mar 12 18:11:35 MST 2012

Quote: Zero
Yes
Haven't seen something funny at USB since years :rolleyes:
I'm no USB expert, but aren't we talking about bulk transfer? AFAIK bulk interval isn't specified, so what you are seeing is bulk transfer using full bandwidth (same thing I'm seeing here)



I got that once-a-millisecond idea from you...http://knowledgebase.nxp.com/showthread.php?t=1101
But I see the bus thrashed all the time whether or not data is being transferred.


Quote: Zero

Not sure what sample we are talking about. Changing LPC1343 USBCDC example to CMSIS 2.0 (nohost) is also working without problems here as CMSIS 1.3 with WIN7/32bit or XP



I tried again with LPCxpresso 4.2 and the revised examples therein. The only modification I made was to add support for printf and a systick interrupt.

int __sys_write(int iFileHandle, char *pcBuffer, int iLength)
{
   int nbytes = 0;
   while(iLength--){
      SER_BUF_WR(ser_in, *pcBuffer++);
      nbytes++;
   }
   return nbytes;
}


void SysTick_Handler(void) {
   msTicks++;                        

   if(msTicks == 10){
      outByteCount += printf("%06d\n", outByteCount);
   }
}


This allowed me to see that comms would fail after a transfer of 12k characters. Forcing a ZLP after 10k did not help when I was merely observing the LPC1343 in a USB protocol analyzer. When I then started Realterm, the ZLPs seemed to be the cure and I am content.

I'm still baffled by the huge amount of activity on the bus [I]when I am sending no data[/I], which implies something pathological in the implementation. But, hey, if you don't care, neither do I.
0 Kudos

390 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Ex-Zero on Sun Mar 11 16:25:23 MST 2012

Quote:

If anyone out there is using USBCDC...

Yes :)

Quote:

...tell me if you see something funny?

Haven't seen something funny at USB since years :rolleyes:

Quote:

I would expect to see traffic in short bursts, once per millisecond, but I see almost constant activity.

I'm no USB expert, but aren't we talking about bulk transfer? AFAIK bulk interval isn't specified, so what you are seeing is bulk transfer using full bandwidth (same thing I'm seeing here) :eek:

Quote:

...use something that 'just works'.

Not sure what sample we are talking about. Changing LPC1343 USBCDC example to CMSIS 2.0 (nohost) is also working without problems here as CMSIS 1.3 with WIN7/32bit or XP :rolleyes:
0 Kudos