USB OTG: function of CHDIS/CHENA

[Doug Brunner]

Posted on December 09, 2017 at 00:32

I'm working with the OTG FS core on the STM32F205ZE, and having some trouble understanding the sequences used in the example code. In the manual (RM0033) under register description for HCCHAR, the CHDIS/CHENA bits are marked 'rs', meaning they can be read and set by the application, but only the USB core can clear them. However, in a number of places in the code, I see things like

  USBx_HC(hc_num)->HCCHAR &= ~USB_OTG_HCCHAR_CHENA;

  USBx_HC(hc_num)->HCCHAR |= USB_OTG_HCCHAR_CHENA;  USBx_HC(hc_num)->HCCHAR &= ~USB_OTG_HCCHAR_EPDIR;

to halt a channel when the request queue is full, and

  tmpreg = USBx_HC(chnum)->HCCHAR;

  tmpreg &= ~USB_OTG_HCCHAR_CHDIS;  tmpreg |= USB_OTG_HCCHAR_CHENA;  USBx_HC(chnum)->HCCHAR = tmpreg;

to start a channel transferring again after receiving a packet.

In my own code, I found that writing a 1 to CHENA (even though it's already set to 1) is indeed necessary to continue an IN bulk transfer after receiving the first packet. Given this, the manual's description cannot be complete. In section 29.17.4, under 'Halting a channel', there is some description of a sequence of writes to CHDIS and CHENA, but it doesn't mention the step of clearing EPDIR as in the example code. I see there was some

https://community.st.com/0D50X00009XkgdNSAR

a while ago, and a partial solution was posted, but it doesn't address how or why the various writes to CHDIS and CHENA work. In particular, there is mention of multiple 1 writes to CHENA scheduling multiple IN tokens, which doesn't appear anywhere in the documentation.

Some clarification from ST would be very helpful here.

#f2 #chena #hcchar #chdis #otg #halt #usb #stm32f2

[Doug Brunner]

Posted on December 12, 2017 at 07:08

I discovered that the cause of some other problems that I was having was setting the FIFO size registers GRXFSIZ, HNPTXFSIZ, and HPTXFSIZ too early. The documentation seems to indicate that they could be set as soon as the AHB and PHY domains are synchronized (3 PHY clocks after CSRST reset completes), but I discovered that if they are set too soon, the values written go into the bit bucket. This leads to the USB core operating with FIFO limits set outside the boundaries of implemented FIFO memory, causing host channels to hang with both CHENA and CHDIS set. In my case I observed this after sending 15 44-byte packets on a single FIFO; instead of a 16th packet as expected, the hardware analyzer showed one 1041-byte monster packet going out on the wire, after which the pipe was unresponsive as described.

I found by bisection search that the problem occurs when the FIFO size registers are set less than 63 ms after CSRST reset. I could not find any way of directly telling when it was safe to write FIFO registers. I also tried setting the registers with code that then read them out again to check, and repeated the write until it was successful; the problem still occurred, and examining the registers at a breakpoint after this code showed the default values in the debugger. I ended up moving the FIFO size configuration to after the device is connected, as in the STM32Cube generated code.

Is this a known behavior of the core?

[waclawek.jan]

Posted on December 12, 2017 at 08:59

 ,

 ,

ST is

http://community.st.com/message/165681 ♯ 165681

to answer OTG-related questions. The fact that it's an IP purchased from Synopsys to be thrown into the more complex STM32 designs without much work, probably also means ST engineers simply don't have the knowledge of the more intimate details.

I ended up moving the FIFO size configuration to after the device is connected, as in the STM32Cube generated code.

This is also what the Host initialization subsubchapter in OTG_xx programming model subchapter indicates to do. This, together with a mysterious 63ms delay might indicate that the FIFO registers - which AFAIK are in the PHY clock domain rather than AHB clock domain - need some sort of PHY clock setup, maybe related to OTG_xx_HCFG.FSLSPCS ?

JW

[Doug Brunner]

Posted on January 03, 2018 at 21:22

Sorry for the delay, thought I was subscribed to notifications for this.

For what it's worth, in the version of my code where I waited 63 ms and then set up FIFO sizes, I didn't set HCFG until after FIFO size setup. Perhaps there's a PLL in there that ST doesn't know about, and it takes an unusually long time to stabilize?

Anyway, thanks for the info - I didn't know ST had just bought the IP core. Unfortunate, since it seems to have more than its share of problems. I learned during a previous run-in that, in device mode, if you get a failed isochronous OUT transfer and you respond by disabling the endpoint as the manual recommends, the core hangs. I only figured that one out when I stumbled across a reference in the ChibiOS code.