LPC1343 USB issue

[lpcware]

Content originally posted in LPCWare by mtburt on Tue Apr 02 18:03:20 MST 2013
Hello,

I'm using the Kiel USB stack on the LPC1343 to do some fairly high bandwidth transfers over a bulk in endpoint.  It's sending 3 64 byte packets every millisecond pretty effectively. But eventually, if I leave data transferring for long enough, the host reports a timeout during the endpoint read.  This occurs every time but the amount of data that is transmitted out varies quite a bit, from 4M packets logged on the endpoint to more than 75M.

Using a beagle USB sniffer to monitor the traffic, everything looks fine until the packet which causes the timeout. The failing packet has an invalid length, instead of the typical 64 bytes being transferred it reports between 900 and 1024 (different value each time), and isn't ACK/NACK-ed by the host.

I can't find any obvious overflows or problems in the code. And it's my understanding that the hardware only supports transfers up to 64 bytes, so if the sniffer is accurate something strange is happening.

I was hoping someone has some insight on this problem or can point me in the right direction.  Any tips would be appreciated.

Thanks in advance,
-Matt

[lpcware]

Content originally posted in LPCWare by Anton.Nikulin on Fri Aug 02 09:44:59 MST 2013
Hello!
I have exactly the same problem with lpc1343.
mtburt, did you solve it?
For testing i wrote some code. Test code uses keil usb cdc example with keil usb stack 1.20.

Test code:

---

Quote:


uint8_t text[] = {
"numbers: 0; text: The quick brown fox jumps over the lazy dog.\r\n" \
"numbers: 1; text: The quick brown fox jumps over the lazy dog.\r\n" \
"numbers: 2; text: The quick brown fox jumps over the lazy dog.\r\n" \
"numbers: 3; text: The quick brown fox jumps over the lazy dog.\r\n" \
"numbers: 4; text: The quick brown fox jumps over the lazy dog.\r\n" \
"numbers: 5; text: The quick brown fox jumps over the lazy dog.\r\n" \
"numbers: 6; text: The quick brown fox jumps over the lazy dog.\r\n" \
"numbers: 7; text: The quick brown fox jumps over the lazy dog.\r\n" \
"numbers: 8; text: The quick brown fox jumps over the lazy dog.\r\n" \
"numbers: 9; text: The quick brown fox jumps over the lazy dog.\r\n" \
};

/**
* @briefHandle interrupt from SysTick timer
* @returnNothing
*/
void SysTick_Handler(void)
{
static uint32_t ctr = 0;

if (CDC_DepInEmpty)
{
CDC_DepInEmpty = FALSE;
USB_WriteEP (CDC_DEP_IN, &text[64*(ctr++%10)], 64);
}

}

---

SysTick handles every 1ms.

[lpcware]

Content originally posted in LPCWare by Tsuneo on Fri Apr 05 14:41:08 MST 2013

---

Quote:
it's using Kiel USB stack version 1.20.

---

I see.

In slave (non-DMA) mode, start_block_transfer() in this snippet will help you.

usbcfg_LPC13xx.h

#define USB_EP_EVENT        0x0009    // EP3 and EP0
#define USB_CONFIGURE_EVENT 1

usbuser.c

#define BULK_EP_IN                0x83
#define BULK_IN_MAX_PACKET_SIZE   64

volatile U8 * bulk_in_buf_ptr;
volatile U32  bulk_in_buf_cnt;
volatile BOOL bulk_in_ep_occupied;

void USB_EndPoint3 (U32 event) {
  U32 packet_size;

  if (event == USB_EVT_IN) {
    if ( bulk_in_buf_cnt ) {
      packet_size = (bulk_in_buf_cnt < BULK_IN_MAX_PACKET_SIZE) ? bulk_in_buf_cnt : BULK_IN_MAX_PACKET_SIZE;
      USB_WriteEP( BULK_EP_IN, bulk_in_buf_ptr, packet_size );
      bulk_in_buf_cnt -= packet_size;
      bulk_in_buf_ptr += packet_size;
    } else {
      bulk_in_ep_occupied = FALSE;
    }
  }
}

#if USB_CONFIGURE_EVENT
void USB_Configure_Event (void) {

  if (USB_Configuration) {                   /* Check if USB is configured */
    bulk_in_buf_ptr = NULL;       // initialize bulk IN EP context
    bulk_in_buf_cnt = 0;
    bulk_in_ep_occupied = FALSE;
  }
}
#endif

BOOL start_block_transfer( U8 * buf, U32 len )
{
    if ( bulk_in_ep_occupied )  return FALSE;
    bulk_in_ep_occupied = TRUE;
    bulk_in_buf_ptr = buf;
    bulk_in_buf_cnt = len;
    LPC_USB->DevIntSet = 1 << (EPAdr(BULK_EP_IN) + 1);   // manually set interrupt flag to trigger
    return TRUE;    
}

Tsuneo

[lpcware]

Content originally posted in LPCWare by mtburt on Fri Apr 05 10:56:38 MST 2013
Thanks for the response.  I believe it's the case that the last message has been sent before the sending the next, but I will try to verify it.

I'm using custom, vendor specific device profile, but it's using Kiel USB stack version 1.20.  Does that help?

Thanks,
-Matt

[lpcware]

Content originally posted in LPCWare by Tsuneo on Thu Apr 04 07:46:48 MST 2013
Did you wait for transaction completion of the bulk IN endpoint, before loading a new packet to the endpoint?
Overwrite to the endpoint may cause such a trouble.

Which example are you starting on, exactly?
If you would show us the original example, we could discuss on the coding details more.

Tsuneo