Some questions about OTG-FS on STM32L4x6

[NMiya.1]

We are trying to Rx Bulk short packet (max packet size 4 bytes) at high speed and with low software load by using the USB HOST core of OTG_FS IP mounted on STM32L476.

Prerequisite condition

・I don't use the code generated by cubemx.

・Host and Device connected one-to-one. (I don't use a hub)

・Activated pipe is bulk-IN pipe ONLY (In steady state, excluding control pipes).

・Max packet size is 8bytes.

・The OTG_FS core is forced to work as a USB host-only(FHMOD@OTG_GUSBCFG = 1).

・AHB CLK is 75MHz.

In implementing the above, I have some questions.

1. debounce completion interrupt (DBCDNE@OTG_GOTGINT)

I'm thinking of using the DBCDNE interrupt waiting for the electrical Debounce period after port connect detected interrupt (PCDET@OTG_HPRT).

However, the Manual states that the DBCDNE interrupt will not occur unless you enable HNPCAP or SRPCAP.

Can DBCDNE interrupt not be used when the host-only mode and HNP/SRP function are not used?

2. NAK interrupt

To reduce the software load, I want to IN-NAK poll by the autonomous operation of the internal sequencer without generating a NAK interrupt each time IN-NAK polls.

But unfortunately, it seems that NAK interrupt enable and interrupt clear by interrupt routine are indispensable for continuous IN-NAK polling.

Is it possible to keep the USB HOST core sequencer operating IN-NAK polling WITHOUT software intervention?

3. IN-NAK polling frequency

I want to increase the frequency of IN-NAK polling by the HOST in order to acquire data at high speed and with strict timing.

Unfortunately, IN-NAK polling is only done 20 times per frame.

Table 5-9 of Universal Serial Bus Specification Revision 2.0 states that, transfer can be issued 71 times per frame when data payload is 8 bytes.

Of course, I think the polling interval will change slightly depending on the response performance of the Target Device....

When the response performance of the target device is not taken into consideration, how many times can the USBHost sequencer issue the IN token per frame?

[waclawek.jan · Accepted solution]

1. I don't know, never used the OTG facilities, but I also don't quite see a reason to doubt the RM in this particular issue

2. No, there is no automated NAK handling in hardware, you have to do it in software.

3. It's probably given be both the host and device software. Observe the bus traffic and toggle pins on both host and device upon begin and end of the stack handling (interrupt) to assess, where may be the main bottleneck.

--

After having fought with the OTG_USB module's quirks for quite some time, I would never even consider it as a viable option to connect two STM32s. YMMV.

JW

[NMiya.1]

Thank you for your reply!!

1. I wondered why the DBCDNE interrupt is useful even if it doesn't use the HNP/SRP function, but why it is so designed.

(I implemented Debounce period wait using an external timer. )

2. It seems that the processing of NAK reception is not described in the section of the programming model of RM. Thanks to you, I have confirmation.

3. Regarding this, it was a rudimentary mistake to use a pile of IF statements to identify the interrupt factor in the ISR.....

I tried to make the number of cycles to clear NAK interrupts as short as possible in the ISR, and I was able to raise it to 133 IN-NAK polls per frame.

As related to Question 2, it was found that the response performance of the SW greatly affects the communication efficiency because the SW must handle the processing of the subdivided granularity.

The attached document is the acquired IN-NAK polling log.

The software load will be heavy, it may be possible to further improve the polling frequency.

Regard