NXP ARM7 USB error handling

Hello,

I have came across an issue when using LPC2368 micro USB in CDC mode I get errors at random time of communication and after them all communication stops.

At the moment system is using V1.10 USB driver from keil examples, USB initializing correctly, data is transferring ok also until error case. Data sending is started from timer which runs at 1ms period, and fills endpoint buffer if any data is ready to be sent and previous data on EP was sent(that is detected if EP_in event was fired)

9:54:37.587> !BuffEmpty || bWait     //Data out buffer not empty in TIM __irq
9:54:37.587> Buff +=  64B            //temp buffer filled with data
9:54:37.587> EP_Send   64B           //temp buffer sent to EP to start sending
9:54:37.587> EP_in           //EP_in received ACK in USB __irq
9:54:37.587> !BuffEmpty || bWait     //Same
9:54:37.587> Buff +=  64B
9:54:37.587> EP_Send   64B
9:54:37.587> EP_in
9:54:37.587> !BuffEmpty || bWait     //Same
9:54:37.587> Buff +=  41B
9:54:37.587> EP_Send   41B
9:54:37.587> EP_in
9:54:38.086> !BuffEmpty || bWait     //Same
9:54:38.086> Buff +=  27B
9:54:38.086> EP_Send   27B
9:54:38.086> EP_in
9:54:43.078> !BuffEmpty || bWait     //Same
9:54:43.078> Buff +=  21B
9:54:43.078> EP_Send   21B
9:54:43.078> EP_in
9:54:43.515> ERROR - 0040|001D               //Errors started firing
9:54:43.515> ERROR - 0001|0011                //1st DWORD is ERROR status (SIE command 0xFB)
9:54:43.515> ERROR - 0041|001D                //2nd DWORD is ERROR code (SIE command 0xFF)
9:54:43.515> ERROR - 0001|0011
9:54:44.201> !BuffEmpty || bWait     //Trying to send next data from TIM __irq
9:54:44.201> Buff +=  48B            //without handling received error
9:54:44.201> EP_Send   48B
9:54:44.201> !bInterrupt             //TIM __irq is detecting that EP_in ACK event wasn't fired yet
...
...
...
9:54:44.201> !bInterrupt
9:54:44.201> !bInterrupt
9:54:44.201> ERROR - 0040|001D               //same stuff is repeating over and over again
9:54:44.201> !bInterrupt             //Errors are firing and data stored in EP_in buffer
9:54:44.201> !bInterrupt             //isn't sending or EP_in ACK event isn't happening
9:54:44.201> !bInterrupt
9:54:44.201> ERROR - 0041|001D
9:54:44.201> ERROR - 0001|0011
9:54:44.201> ERROR - 0040|001D
9:54:44.201> !bInterrupt
9:54:44.201> !bInterrupt
9:54:44.201> ERROR - 0001|0011
9:54:44.201> ERROR - 0040|001D
9:54:44.201> ERROR - 0041|001D
9:54:44.201> ERROR - 0041|0011
9:54:44.201> !bInterrupt
9:54:44.201> !bInterrupt
9:54:44.201> ERROR - 0040|001D
9:54:44.201> ERROR - 0001|0011
9:54:44.201> ERROR - 0041|001D
9:54:44.201> ERROR - 0041|0011
9:54:44.201> ERROR - 0040|001D
9:54:44.201> !bInterrupt
9:54:44.201> !bInterrupt
...
...
...

maybe anyone have any suggestions how to act in such situation in order to restore communication?

Thank you in advance,
Laurynas

Parents
  • Are you working on Windows CDC driver, usbser.sys?

    Your trace shows no error recovery by the PC driver, which is the defect of usbser.sys.

    The CDC host always polls the bulk IN endpoint, even while nothing is loaded on the bulk IN endpoint. You'll see IN-NAK transactions (30 - 40 / frame) fills the bus timing. When burst noise occurs on the bus (or on your board), this IN-NAK transactions are disturbed. The erros detected by your device should be caused by disturbed IN-NAK transactions.

    When transaction error is detected, host hardware (HC: host controller) retries the transaction two times more. At the third retry error, the HC gives up retry, and it passes error to the PC device driver. Decent PC device driver puts error recovery sequence to the bulk IN endpoint - such as pipe reset. But usbser.sys silently stops bulk-IN polling.

    CDC - stalled bulk IN
    www.microchip.com/.../tm.aspx

    If it were usbser.sys, recovery from this error should be troublesome.

    Tsuneo

Reply
  • Are you working on Windows CDC driver, usbser.sys?

    Your trace shows no error recovery by the PC driver, which is the defect of usbser.sys.

    The CDC host always polls the bulk IN endpoint, even while nothing is loaded on the bulk IN endpoint. You'll see IN-NAK transactions (30 - 40 / frame) fills the bus timing. When burst noise occurs on the bus (or on your board), this IN-NAK transactions are disturbed. The erros detected by your device should be caused by disturbed IN-NAK transactions.

    When transaction error is detected, host hardware (HC: host controller) retries the transaction two times more. At the third retry error, the HC gives up retry, and it passes error to the PC device driver. Decent PC device driver puts error recovery sequence to the bulk IN endpoint - such as pipe reset. But usbser.sys silently stops bulk-IN polling.

    CDC - stalled bulk IN
    www.microchip.com/.../tm.aspx

    If it were usbser.sys, recovery from this error should be troublesome.

    Tsuneo

Children
More questions in this forum