omap_udc does not respond to SETUP transfer properly (OMAP5912)

DISCUSSION Steve Poulsen 2 participants 4 messages Mar 15, 2007 – Mar 16, 2007

Share & tools

Steve Poulsen

author

2007-03-15 18:42 UTC #0 lore raw

When I plug our device into a Windows PC, we receive the SETUP message (USB_REQ_GET_DESCRIPTOR). The IRQ handler sets the EP_NUM values per Figure 16 of SPRU761A (EP_NUM.EPU_NUM = 0, EP_DIR = 1, EP_SEL = 1, SETUP_SEL=0), then it writes the response into the fifo. After writing, FIFO_EN is set to 1, then EP_SEL to 0. I then find it remains in this state forever (or at least until Windows decides the device is problematic and turns it off). I have looked at the STAT register at the start of the IRQ and it shows the FIFO is empty (0x02). After writing the STAT register shows (0x04) as expected. However, even waiting 500 ms after the write, the STAT still shows 0x04.

I have confirmed the HHC and DC clocks are enabled by looking at SOFT_REQ_REG and MOD_CONF_CTRL_0.

Shouldn't the STAT 0x04 bit go to zero eventually and it show the fifo empty once again?

Thanks,

Steve

Pandita, Vikram

2007-03-16 04:51 UTC #1 lore raw

Have you tried the Interrupt mode of transfer.
In this mode you will be writing directly to the FIFO the response of GET_DESCRIPTOR. Later you can debug the DMA path.

Quoted 2 lines

-----Original Message-----
From: [email protected]

[mailto:linux-omap-

Quoted 4 lines

[email protected]] On Behalf Of Steve Poulsen
Sent: Friday, March 16, 2007 12:13 AM
To: [email protected]
Subject: omap_udc does not respond to SETUP transfer properly

(OMAP5912)

Quoted 5 lines

When I plug our device into a Windows PC, we receive the SETUP message (USB_REQ_GET_DESCRIPTOR). The IRQ handler sets the EP_NUM values per Figure 16 of SPRU761A (EP_NUM.EPU_NUM = 0, EP_DIR = 1, EP_SEL = 1, SETUP_SEL=0), then it writes the response into the fifo. After

writing,

Quoted 4 lines

FIFO_EN is set to 1, then EP_SEL to 0. I then find it remains in this state forever (or at least until Windows decides the device is problematic and turns it off).
I have looked at the STAT register at the start of the IRQ and it

shows

Quoted 1 line

the FIFO is empty (0x02). After writing the STAT register shows

(0x04)

Quoted 18 lines

as expected. However, even waiting 500 ms after the write, the STAT still shows 0x04.
I have confirmed the HHC and DC clocks are enabled by looking at SOFT_REQ_REG and MOD_CONF_CTRL_0.
Shouldn't the STAT 0x04 bit go to zero eventually and it show the fifo empty once again?
Thanks,
Steve
_______________________________________________
Linux-omap-open-source mailing list
[email protected]
http://linux.omap.com/mailman/listinfo/linux-omap-open-source

Steve Poulsen

author

2007-03-16 15:26 UTC #2 lore raw

Thanks for the quick response. Yes, this is the mode that I am using. I get only one interrupt for the SETUP and then nothing there-after. If I cut-out the function calls and some unimportant code (for simplicity), here are the steps the Linux drivers go through for this GET_DESCRIPTOR:

       do {
           UDC_EP_NUM_REG = UDC_SETUP_SEL;
           /* two bytes at a time */
           u.word[0] = UDC_DATA_REG;
           u.word[1] = UDC_DATA_REG;
           u.word[2] = UDC_DATA_REG;
           u.word[3] = UDC_DATA_REG;
           UDC_EP_NUM_REG = 0;
       } while (UDC_IRQ_SRC_REG & UDC_SETUP);

       UDC_EP_NUM_REG = UDC_EP_SEL|UDC_EP_DIR;
       write_packet();  // Loops to write the whole packet to UDC_DATA_REG
       UDC_CTRL_REG = UDC_SET_FIFO_EN;
       UDC_EP_NUM_REG &= ~UDC_EP_SEL;

Thanks,

Steve

Or course, this is all from the driver and using printk() I have determined this is the flow through the driver.

Quoted 58 lines · Vikram

Have you tried the Interrupt mode of transfer.
In this mode you will be writing directly to the FIFO the response of GET_DESCRIPTOR. Later you can debug the DMA path.
Quoted 3 lines
-----Original Message-----
From: [email protected]
[mailto:linux-omap-
Quoted 5 lines
[email protected]] On Behalf Of Steve Poulsen
Sent: Friday, March 16, 2007 12:13 AM
To: [email protected]
Subject: omap_udc does not respond to SETUP transfer properly
(OMAP5912)
Quoted 5 lines
When I plug our device into a Windows PC, we receive the SETUP message (USB_REQ_GET_DESCRIPTOR). The IRQ handler sets the EP_NUM values per Figure 16 of SPRU761A (EP_NUM.EPU_NUM = 0, EP_DIR = 1, EP_SEL = 1, SETUP_SEL=0), then it writes the response into the fifo. After
writing,
Quoted 5 lines
FIFO_EN is set to 1, then EP_SEL to 0. I then find it remains in this state forever (or at least until Windows decides the device is problematic and turns it off).
I have looked at the STAT register at the start of the IRQ and it
shows
Quoted 2 lines
the FIFO is empty (0x02). After writing the STAT register shows
(0x04)
Quoted 19 lines
as expected. However, even waiting 500 ms after the write, the STAT still shows 0x04.
I have confirmed the HHC and DC clocks are enabled by looking at SOFT_REQ_REG and MOD_CONF_CTRL_0.
Shouldn't the STAT 0x04 bit go to zero eventually and it show the fifo empty once again?
Thanks,
Steve
_______________________________________________
Linux-omap-open-source mailing list
[email protected]
http://linux.omap.com/mailman/listinfo/linux-omap-open-source

Steve Poulsen

author

2007-03-16 18:44 UTC #3 lore raw

In reply to Pandita, Vikram

I appear to get strange results from the UDC registers. In omap_ep_queue(), there is some code that sets up the EP_NUM register before writing to the fifo. I added some printk() lines around here to see what is going on. Even the revision register produces a value that doesn't agree with the possible documented values. Notice that the write to EP_NUM_REG doesn't do anything.

           /* non-empty DATA stage */
           } else if (is_in) {
   printk(KERN_ALERT "UDC_EP_NUM_REG = 0x%08x\n", UDC_EP_NUM_REG);
               UDC_EP_NUM_REG = UDC_EP_SEL|UDC_EP_DIR;
               //*((volatile int*)0xfefb4004)  = UDC_EP_SEL|UDC_EP_DIR;

// doesn't help
printk(KERN_ALERT "UDC_EP_NUM_REG = 0x%08x\n", *((volatile
int*)0xfefb4004));
printk(KERN_ALERT "UDC_REV_REG = 0x%08x\n", *((volatile
int*)0xfefb4000));
printk(KERN_ALERT "UDC_OTG_SYSCON1 = 0x%08x\n", *((volatile

int*)0xfefb0404));
           } else {
               if (udc->ep0_setup)
                   goto irq_wait;
               UDC_EP_NUM_REG = UDC_EP_SEL;
           }

MOD_CONF_CTRL_0 :  0xe0005200
SOFT_REQ_REG    :  0x00000758

...
UDC_EP_NUM_REG = 0x00000000
UDC_EP_NUM_REG = 0x00000000
UDC_REV_REG = 0x00000036
UDC_OTG_SYSCON1 = 0x00030004

Thanks,

Steve

Quoted 58 lines · Vikram

Have you tried the Interrupt mode of transfer.
In this mode you will be writing directly to the FIFO the response of GET_DESCRIPTOR. Later you can debug the DMA path.
Quoted 3 lines
-----Original Message-----
From: [email protected]
[mailto:linux-omap-
Quoted 5 lines
[email protected]] On Behalf Of Steve Poulsen
Sent: Friday, March 16, 2007 12:13 AM
To: [email protected]
Subject: omap_udc does not respond to SETUP transfer properly
(OMAP5912)
Quoted 5 lines
When I plug our device into a Windows PC, we receive the SETUP message (USB_REQ_GET_DESCRIPTOR). The IRQ handler sets the EP_NUM values per Figure 16 of SPRU761A (EP_NUM.EPU_NUM = 0, EP_DIR = 1, EP_SEL = 1, SETUP_SEL=0), then it writes the response into the fifo. After
writing,
Quoted 5 lines
FIFO_EN is set to 1, then EP_SEL to 0. I then find it remains in this state forever (or at least until Windows decides the device is problematic and turns it off).
I have looked at the STAT register at the start of the IRQ and it
shows
Quoted 2 lines
the FIFO is empty (0x02). After writing the STAT register shows
(0x04)
Quoted 19 lines
as expected. However, even waiting 500 ms after the write, the STAT still shows 0x04.
I have confirmed the HHC and DC clocks are enabled by looking at SOFT_REQ_REG and MOD_CONF_CTRL_0.
Shouldn't the STAT 0x04 bit go to zero eventually and it show the fifo empty once again?
Thanks,
Steve
_______________________________________________
Linux-omap-open-source mailing list
[email protected]
http://linux.omap.com/mailman/listinfo/linux-omap-open-source