AT91RM9200 (arm) and usb device control transfer

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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



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

Quoted text here. Click to load it



Re: AT91RM9200 (arm) and usb device control transfer

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


Quoted text here. Click to load it


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


Quoted text here. Click to load it



Site Timeline