1. Home
  2. Embedded Linux
  3. AT91RM9200 (arm) and usb device control transfer

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

Reply to
wet
Loading thread data ...

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).

  1. 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,

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

  1. 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

Reply to
Marc Reinig

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

Reply to
wet

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

Reply to
Marc Reinig

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.