• State Not Answered
  • Locked Locked
  • Replies 23 replies
  • Subscribers 22 subscribers
  • Views 3361 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

LPC2478 USB device interrupt status question

Tamir Michael

Hello,

Sometimes, my controller hangs after being polled by a CDC connection. I see when I debug the ISR that my device status registers contains the vale 0x41 (11110001),
which can be interpreted using the following data sheet table:

bit0 The frame interrupt occurs every 1 ms. This is used in isochronous packet transfers.

bit1 Fast endpoint interrupt. If an Endpoint Interrupt Priority register (USBEpIntPri) bit is
set, the corresponding endpoint interrupt will be routed to this bit.

bit2 Slow endpoints interrupt. If an Endpoint Interrupt Priority Register (USBEpIntPri) bit is
not set, the corresponding endpoint interrupt will be routed to this bit.

bit3 Set when USB Bus reset, USB suspend change or Connect change event occurs.
Refer to Section 13â€"11.6 “Set Device Status (Command: 0xFE, Data: write 1 byte)†on page 366.

bit4 The command code register (USBCmdCode) is empty (New command can be written).

bit5 Command data register (USBCmdData) is full (Data can be read now).

bit6 The current packet in the endpoint buffer is transferred to the CPU.

bit7 The number of data bytes transferred to the endpoint buffer equals the number of bytes programmed in the TxPacket length register (USBTxPLen).

I don't fully understand why this is happening (it just appears after some time; no endpoint is triggered anymore as a result). Windows issue? software failure?
Thanks in advance

Parents
  • 0 in reply to Tamir Michael

    Tamir,

    > how can I send a ZLP packet using Keil's software? is attempt to send an empty buffer good enough?

    That's right.

    USB_WriteEP(EP_address, NULL, 0); // put ZLP to EP

    > no endpoint is triggered anymore as a result

    In most case of CDC firmware, EP interrupt is used just to raise a flag.
    Your firmware polls this flag and processes data, in your main line superloop, or timered polling, or in an ISR other than USB (timer, ADC, ...).
    For IN EP, your firmware checks this flag to know the EP buffer is empty. And then, it passes data to the EP.
    For OUT EP, your firmware knows data is sent from host by this flag. And then, it unloads the data from the EP and processes the data.

    When the firmware sends/receives large data more than wMaxPacketSize (64 bytes) at a time, the first packet is handled like above, but the second and more packets are handled in the EP ISR.

    In this way, your firmware can process USB traffic at the timing as it likes.
    It straightens the code flow, makes your life easy.

    When USB_WriteEP() and USB_ReadEP() is called from mainline code, guard these calls disabling USB interrupt around the calls. Or, apply SWI for these calls.
    It was discussed once in this topic.
    http://www.keil.com/forum/docs/thread15613.asp

    Tsuneo

Reply
  • 0 in reply to Tamir Michael

    Tamir,

    > how can I send a ZLP packet using Keil's software? is attempt to send an empty buffer good enough?

    That's right.

    USB_WriteEP(EP_address, NULL, 0); // put ZLP to EP

    > no endpoint is triggered anymore as a result

    In most case of CDC firmware, EP interrupt is used just to raise a flag.
    Your firmware polls this flag and processes data, in your main line superloop, or timered polling, or in an ISR other than USB (timer, ADC, ...).
    For IN EP, your firmware checks this flag to know the EP buffer is empty. And then, it passes data to the EP.
    For OUT EP, your firmware knows data is sent from host by this flag. And then, it unloads the data from the EP and processes the data.

    When the firmware sends/receives large data more than wMaxPacketSize (64 bytes) at a time, the first packet is handled like above, but the second and more packets are handled in the EP ISR.

    In this way, your firmware can process USB traffic at the timing as it likes.
    It straightens the code flow, makes your life easy.

    When USB_WriteEP() and USB_ReadEP() is called from mainline code, guard these calls disabling USB interrupt around the calls. Or, apply SWI for these calls.
    It was discussed once in this topic.
    http://www.keil.com/forum/docs/thread15613.asp

    Tsuneo

Children