LPC11U24 USB CDC command reception error

lpcware · ‎06-15-2016

Content originally posted in LPCWare by saraswathi on Thu Jun 20 04:17:28 MST 2013
[FONT=Arial][SIZE=2]Hi,[/SIZE][/FONT]
[FONT=Arial][SIZE=2][/SIZE][/FONT]
[FONT=Arial][SIZE=2]I am working on LPC11U24 based USB CDC class device. The functionality of this device is to receive the commands from host and send the data to host or configure the other IOs.[/SIZE][/FONT]
[FONT=Arial][SIZE=2]I am using the USB CDC class sample code from [/SIZE][/FONT][FONT=Arial][SIZE=2][COLOR=#0000ff]http://www.lpcware.com/node/11538/128[/COLOR][/SIZE][/FONT]
[FONT=Arial][SIZE=2]I have customized this sample code with removing the source code implemented inside the macro, "#if defined(UART_BRIDGE)". [/SIZE][/FONT]
[FONT=Arial][SIZE=2][/SIZE][/FONT]
[FONT=Arial][SIZE=2]After doing the above said customization, I am observing behavior as mentioned below.[/SIZE][/FONT]
[FONT=Arial][SIZE=2]1) Host asks for I2C data using "VCOM_bulk_out_hdlr". [/SIZE][/FONT]
[FONT=Arial][SIZE=2]2) I2C data is read and transferd to the host using "VCOM_usb_send"[/SIZE][/FONT]
[FONT=Arial][SIZE=2]3) ACK is received by "VCOM_bulk_out_hdlr". I am ignoring this value and returning LPC_OK.[/SIZE][/FONT]
[FONT=Arial][SIZE=2]4) Host sends command to the device. But VCOM_bulk_out_hdlr is not at all called. Hence device is not working.[/SIZE][/FONT]
[FONT=Arial][SIZE=2][/SIZE][/FONT]
[FONT=Arial][SIZE=2]Can anyone please let me know why VCOM_bulk_out_hdlr is not called while host sending the command second time?[/SIZE][/FONT]
[FONT=Arial][SIZE=2]Since I am not clearing the ACK, is it creating the problem?[/SIZE][/FONT]
[FONT=Arial][SIZE=2][/SIZE][/FONT]
[FONT=Arial][SIZE=2]Thanks in advance.[/SIZE][/FONT]
[FONT=Arial][SIZE=2][/SIZE][/FONT]
[FONT=Arial][SIZE=2]With regards[/SIZE][/FONT]
[FONT=Arial][SIZE=2]Saraswathi C[/SIZE][/FONT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by saraswathi on Fri Jun 21 04:59:25 MST 2013
Thank you for the inputs Tsuneo.

I am able to solve the Hardfault. The Buffer clearing method used at the first time data reception was causing the Hardfault at the second time data reception.
After correcting this, it is working fine.

Thanks alot for the help.

With regards
Saraswathi C

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Tsuneo on Thu Jun 20 10:11:03 MST 2013

Quote:
When I tried reading the ACK using pUsbApi->hw->ReadEP( ), Hardfault was occuring.

Did you pass these buffers to ReadEP() and WriteEP()?

main()
      ...
      /* allocate transfer buffers */
      g_vCOM.rxBuf = (uint8_t*)(cdc_param.mem_base + (0 * USB_HS_MAX_BULK_PACKET));
      g_vCOM.txBuf = (uint8_t*)(cdc_param.mem_base + (1 * USB_HS_MAX_BULK_PACKET));

Quote:
Is the ACK a NULL character?

ACK packet on the bus isn't seen on the firmware.
The firmware should see the data sent by your PC application.

Tsuneo

lpcware · ‎06-15-2016

Content originally posted in LPCWare by saraswathi on Thu Jun 20 06:39:28 MST 2013
Hi Tsuneo,

When I tried reading the ACK using pUsbApi->hw->ReadEP( ), Hardfault was occuring. Hence I tried to skip the step pUsbApi->hw->ReadEP( ) and just returning LPC_OK when ACK occurs.

Is the ACK a NULL character? I couldn't make out the reason for Hardfault.

With regards
Saraswathi C

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Tsuneo on Thu Jun 20 06:15:23 MST 2013

Quote:
3) ACK is received by "VCOM_bulk_out_hdlr". I am ignoring this value and returning LPC_OK.

Did you call pUsbApi->hw->ReadEP() at this stage?

VCOM_bulk_out_hdlr() is registered as a callback of the bulk OUT endpoint interrupt.

main()
{
    ...
    /* register endpoint interrupt handler */
    ep_indx = ((USB_CDC_EP_BULK_OUT & 0x0F) << 1);
    ret = pUsbApi->core->RegisterEpHandler (hUsb, ep_indx, VCOM_bulk_out_hdlr, &g_vCOM);

And then, VCOM_bulk_out_hdlr() should be called when the bulk OUT endpoint finishes a transaction. But if the bulk OUT EP would still have the last packet, the endpoint sould return NAK to the new OUT transactions, until ReadEP() unloads the packet.

Tsuneo