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

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
  • Hello Tsuneo,

    I did not yet recreate this problem while a sniffer hangs on the bus. however, I can say that the device's endpoints are never triggered once it goes wrong (however, I have here a system running all night long without a failure). the ISR in the device is triggered, it is only that the endpoints are not. I did not write the PC side application so I cannot tell what its serial calls return...

    Reset the device driver with IOCTL_SERIAL_RESET_DEVICE

    I understand that this can only be done fro the PC side...?
    Not being a USB expert, how can I send a ZLP packet using Keil's software? is attempt to send an empty buffer good enough?

Reply
  • Hello Tsuneo,

    I did not yet recreate this problem while a sniffer hangs on the bus. however, I can say that the device's endpoints are never triggered once it goes wrong (however, I have here a system running all night long without a failure). the ISR in the device is triggered, it is only that the endpoints are not. I did not write the PC side application so I cannot tell what its serial calls return...

    Reset the device driver with IOCTL_SERIAL_RESET_DEVICE

    I understand that this can only be done fro the PC side...?
    Not being a USB expert, how can I send a ZLP packet using Keil's software? is attempt to send an empty buffer good enough?

Children
  • 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