AT91RM9200 (arm) and usb device control transfer - Embedded

This is a discussion on AT91RM9200 (arm) and usb device control transfer - Embedded ; Hi, I'm trying to write usb *device* driver for AT91RM9200 - for linux kernel 2.6.14. I know there is already written this driver in this linux, but I'd like to write it from the scratch on my own. At present ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: AT91RM9200 (arm) and usb device control transfer

  1. AT91RM9200 (arm) and usb device control transfer

    Hi,

    I'm trying to write usb *device* driver for AT91RM9200 - for linux kernel
    2.6.14. I know there is already written this driver in this linux, but
    I'd like to write it from the scratch on my own. At present I've got
    configured the usb device controller on the AT91 side (48Mhz freq,
    pullup, etc). As the usb host side I'm using PC with 2.6.25 kernel
    and uhci host driver. Now I'm able to receive following setup tokens
    from PC: get_device_descriptor and set_address. I've got problems
    with handling get_dev_descriptor request. When arm receives setup
    token - it generates interrupt - so I know that there are some data in
    RX-FIFO and I can read it. But I don't know when the IN token comes,
    because arm doesn't issue any interrupt. Does anyone know why arm
    doesn't generate such interrupt? Maybe I'm doing something wrong - there
    is not any explanation of SETUP-IN sequence in documentation.
    There is only SETUP-OUT sequence described in docs. Is there any other
    docs for USB device module for AT91RM9200 on the net?

    wet



  2. Re: AT91RM9200 (arm) and usb device control transfer

    When you receive a request for a device descriptor, you should place the
    descriptor in the fifo. The device should send that automatically on an in
    token and notify you with an interrupt when it is done. Have you done that?
    This is from the docs.
    1. The microcontroller checks if it is possible to write in the FIFO by
    polling TXPKTRDY in the endpointís UDP_CSRx register (TXPKTRDY must be
    cleared).

    2. The microcontroller writes data to be sent in the endpointís FIFO,
    writing zero or more byte values in the endpointís UDP_FDRx register,

    3. The microcontroller notifies the USB peripheral it has finished by
    setting the TXPKTRDY in the endpointís UDP_CSRx register,

    4. The microcontroller is notified that the endpointís FIFO has been
    released by the USB device when TXCOMP in the endpointís UDP_CSRx register
    has been set. Then an interrupt for the corresponding endpoint is pending
    while TXCOMP is set.


    Marco
    ________________________
    Marc Reinig
    UCO/Lick Observatory
    Laboratory for Adaptive Optics

    wrote in message
    news:g351fu$6qk$2@atlantis.news.neostrada.pl...
    > Hi,
    >
    > I'm trying to write usb *device* driver for AT91RM9200 - for linux kernel
    > 2.6.14. I know there is already written this driver in this linux, but
    > I'd like to write it from the scratch on my own. At present I've got
    > configured the usb device controller on the AT91 side (48Mhz freq,
    > pullup, etc). As the usb host side I'm using PC with 2.6.25 kernel
    > and uhci host driver. Now I'm able to receive following setup tokens
    > from PC: get_device_descriptor and set_address. I've got problems
    > with handling get_dev_descriptor request. When arm receives setup
    > token - it generates interrupt - so I know that there are some data in
    > RX-FIFO and I can read it. But I don't know when the IN token comes,
    > because arm doesn't issue any interrupt. Does anyone know why arm
    > doesn't generate such interrupt? Maybe I'm doing something wrong - there
    > is not any explanation of SETUP-IN sequence in documentation.
    > There is only SETUP-OUT sequence described in docs. Is there any other
    > docs for USB device module for AT91RM9200 on the net?
    >
    > wet
    >
    >




  3. Re: AT91RM9200 (arm) and usb device control transfer

    Marc Reinig wrote:

    Hello,

    I thought that arm will generate interrupt after both: SETUP and IN tokens,
    but it comes only after SETUP. So - for now when I receive SETUP for
    get_descriptor - I'm sending first 8 bytes of descriptor *immediately*
    through fifo. Of course I have to check if the TXPKTRDY is cleared before
    placing any data in fifo. After that I'm setting TXPKTRDY to notify usb
    device that it can send DATA-IN packet.

    It's look like interrupt is generating only as acknowldge by host after
    receiving DATA-IN packets from our device but not after receiving IN token
    from host. So we have to assume that host has sent IN token after SETUP
    packet because we cannot recognize coming of this token basing on
    interrupts or any register status.

    I have also question about DIR bit. I know that I have to set it before
    sending response for DATA-IN packets, but I don't know if I have to clear
    it before status stage in for example: setup-in-out transactions?
    In other words - after SETUP and before accepting IN packet from host
    I have set DIR bit, but should I have to clear it after finished IN
    transcation and just before next OUT token?


    wet


    > When you receive a request for a device descriptor, you should place the
    > descriptor in the fifo. The device should send that automatically on an in
    > token and notify you with an interrupt when it is done. Have you done that?
    > This is from the docs.
    > 1. The microcontroller checks if it is possible to write in the FIFO by
    > polling TXPKTRDY in the endpoint?s UDP_CSRx register (TXPKTRDY must be
    > cleared).
    >
    > 2. The microcontroller writes data to be sent in the endpoint?s FIFO,
    > writing zero or more byte values in the endpoint?s UDP_FDRx register,
    >
    > 3. The microcontroller notifies the USB peripheral it has finished by
    > setting the TXPKTRDY in the endpoint?s UDP_CSRx register,
    >
    > 4. The microcontroller is notified that the endpoint?s FIFO has been
    > released by the USB device when TXCOMP in the endpoint?s UDP_CSRx register
    > has been set. Then an interrupt for the corresponding endpoint is pending
    > while TXCOMP is set.
    >
    >
    > Marco
    > ________________________
    > Marc Reinig
    > UCO/Lick Observatory
    > Laboratory for Adaptive Optics
    >
    > wrote in message
    > news:g351fu$6qk$2@atlantis.news.neostrada.pl...
    >> Hi,
    >>
    >> I'm trying to write usb *device* driver for AT91RM9200 - for linux kernel
    >> 2.6.14. I know there is already written this driver in this linux, but
    >> I'd like to write it from the scratch on my own. At present I've got
    >> configured the usb device controller on the AT91 side (48Mhz freq,
    >> pullup, etc). As the usb host side I'm using PC with 2.6.25 kernel
    >> and uhci host driver. Now I'm able to receive following setup tokens
    >> from PC: get_device_descriptor and set_address. I've got problems
    >> with handling get_dev_descriptor request. When arm receives setup
    >> token - it generates interrupt - so I know that there are some data in
    >> RX-FIFO and I can read it. But I don't know when the IN token comes,
    >> because arm doesn't issue any interrupt. Does anyone know why arm
    >> doesn't generate such interrupt? Maybe I'm doing something wrong - there
    >> is not any explanation of SETUP-IN sequence in documentation.
    >> There is only SETUP-OUT sequence described in docs. Is there any other
    >> docs for USB device module for AT91RM9200 on the net?
    >>
    >> wet
    >>



  4. Re: AT91RM9200 (arm) and usb device control transfer

    IN tokens come _immediately_ after the SETUP packet, so there is no need to
    be notified when they arrive. If you haven't loaded the FIFO, the device
    will automatically issue a NAK to the host for each IN packet. When you
    load the FIFO, the data will be sent on the next IN, etc. until the
    transaction is complete.



    In terms of the DIR bit, I don't know anything about your device, but I
    assume the bit has to do with the FIFO. The OUT of a SETUP-IN-OUT is a
    status signal and I doubt that any data is passed to the FIFO, so I don't
    think you would need to change the state of the bit. However, I'm sure it
    will be immediately obvious if you do ;=)


    Marco
    ________________________
    Marc Reinig
    UCO/Lick Observatory
    Laboratory for Adaptive Optics


    wrote in message
    news:g3cs05$47f$1@atlantis.news.neostrada.pl...
    > Marc Reinig wrote:
    >
    > Hello,
    >
    > I thought that arm will generate interrupt after both: SETUP and IN
    > tokens,
    > but it comes only after SETUP. So - for now when I receive SETUP for
    > get_descriptor - I'm sending first 8 bytes of descriptor *immediately*
    > through fifo. Of course I have to check if the TXPKTRDY is cleared before
    > placing any data in fifo. After that I'm setting TXPKTRDY to notify usb
    > device that it can send DATA-IN packet.
    >
    > It's look like interrupt is generating only as acknowldge by host after
    > receiving DATA-IN packets from our device but not after receiving IN token
    > from host. So we have to assume that host has sent IN token after SETUP
    > packet because we cannot recognize coming of this token basing on
    > interrupts or any register status.
    >
    > I have also question about DIR bit. I know that I have to set it before
    > sending response for DATA-IN packets, but I don't know if I have to clear
    > it before status stage in for example: setup-in-out transactions?
    > In other words - after SETUP and before accepting IN packet from host
    > I have set DIR bit, but should I have to clear it after finished IN
    > transcation and just before next OUT token?
    >
    >
    > wet
    >
    >
    >> When you receive a request for a device descriptor, you should place the
    >> descriptor in the fifo. The device should send that automatically on an
    >> in
    >> token and notify you with an interrupt when it is done. Have you done
    >> that?
    >> This is from the docs.
    >> 1. The microcontroller checks if it is possible to write in the FIFO by
    >> polling TXPKTRDY in the endpoint?s UDP_CSRx register (TXPKTRDY must be
    >> cleared).
    >>
    >> 2. The microcontroller writes data to be sent in the endpoint?s FIFO,
    >> writing zero or more byte values in the endpoint?s UDP_FDRx register,
    >>
    >> 3. The microcontroller notifies the USB peripheral it has finished by
    >> setting the TXPKTRDY in the endpoint?s UDP_CSRx register,
    >>
    >> 4. The microcontroller is notified that the endpoint?s FIFO has been
    >> released by the USB device when TXCOMP in the endpoint?s UDP_CSRx
    >> register
    >> has been set. Then an interrupt for the corresponding endpoint is pending
    >> while TXCOMP is set.
    >>
    >>
    >> Marco
    >> ________________________
    >> Marc Reinig
    >> UCO/Lick Observatory
    >> Laboratory for Adaptive Optics
    >>
    >> wrote in message
    >> news:g351fu$6qk$2@atlantis.news.neostrada.pl...
    >>> Hi,
    >>>
    >>> I'm trying to write usb *device* driver for AT91RM9200 - for linux
    >>> kernel
    >>> 2.6.14. I know there is already written this driver in this linux, but
    >>> I'd like to write it from the scratch on my own. At present I've got
    >>> configured the usb device controller on the AT91 side (48Mhz freq,
    >>> pullup, etc). As the usb host side I'm using PC with 2.6.25 kernel
    >>> and uhci host driver. Now I'm able to receive following setup tokens
    >>> from PC: get_device_descriptor and set_address. I've got problems
    >>> with handling get_dev_descriptor request. When arm receives setup
    >>> token - it generates interrupt - so I know that there are some data in
    >>> RX-FIFO and I can read it. But I don't know when the IN token comes,
    >>> because arm doesn't issue any interrupt. Does anyone know why arm
    >>> doesn't generate such interrupt? Maybe I'm doing something wrong - there
    >>> is not any explanation of SETUP-IN sequence in documentation.
    >>> There is only SETUP-OUT sequence described in docs. Is there any other
    >>> docs for USB device module for AT91RM9200 on the net?
    >>>
    >>> wet
    >>>

    >




+ Reply to Thread