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


<wet@xxxxxxxxxxxx> wrote in message
news:g3cs05$47f$1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Marc Reinig <Marco@xxxxxxxxxxxxxxxxx> 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

<wet@xxxxxxxxxxxx> wrote in message
news:g351fu$6qk$2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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




.

Relevant Pages

  • Re: AT91RM9200 (arm) and usb device control transfer
    ... The microcontroller checks if it is possible to write in the FIFO by ... released by the USB device when TXCOMP in the endpoint?s UDP_CSRx register ... Then an interrupt for the corresponding endpoint is pending ... Now I'm able to receive following setup tokens ...
    (comp.os.linux.embedded)
  • Re: AT91RM9200 (arm) and usb device control transfer
    ... I thought that arm will generate interrupt after both: SETUP and IN tokens, ... The microcontroller notifies the USB peripheral it has finished by ...
    (comp.os.linux.embedded)
  • Re: Testing box available.
    ... tokens in it and all child makes inherrit this fifo ... The scheduler needs to gain knowledge of the CPU core topology in order to avoid making bad decisions about migrating processes between CPU cores that are far apart. ... Actually it would be interesting to repeat some of our "standard tests" on the barcelona system to see how it compares to the intel one. ...
    (freebsd-current)
  • Re: Testing box available.
    ... make -j64 <foo> ... it only spawns 64 processes to handle the top level make process. ... my memory is that ohk changed make to have a fifo with N ... tokens in it and all child makes inherrit this fifo ...
    (freebsd-current)
  • Re: FIFO Full logix - V4
    ... port and an 8-bit read port using asynchronous clocks. ... programmable option...it uses the default setup in COREGen. ... Detecting FULL in an asynchronous FIFO is a tricky procedure. ...
    (comp.arch.fpga)