No data actually being sent on Iso IN transfer with STM32F429 and USB3320 PHY in HS mode?

[timistof]

For the last week, I've been trying to get asynchronous USB Audio 2.0 to work.

I have dissected the descriptors from a Focusrite Scarlett 2i2 and crafted my own with the usb audio 2.0 docs at hand. I've modified the CubeF4 audio example and kept most of the scaffolding in tact.

Thus far, my device device enumerates as a High Speed device, shows up and I can also stream audio to it, great! The OUT endpoint is working for the output channels, but the IN feedback endpoint does not.

The tricky thing with the feedback endpoint is that the host sends a IN transfer to poll it every 8 microframes (= 1ms). Because I don't know at which frame (odd or even SOF number) the host will first request the feedback value, I have the following trick:

• Prime the feedback endpoint with 1st feedback value when the interface is first opened (alt_setting = 1) by calling USBD_LL_Transmit().
• IsoINIncomplete callbacks are made for every frame that the host didn't poll the data. Every time this happens, I flip the odd/even frame in the DIEPCTL register.
• Eventually, the host inits a IN-transfer, the primed packet is sent and my transfer complete callback is called. In the callback, I prime the endpoint with a new feedback value and the cycle resets.

I'm pulsing GPIO pins for the various callbacks and with a logic analyzer I can see the various callbacks being made when playing audio.

With Wireshark, I can see the the IN-transfers being submitted, but no data is ever actually received, despite transfer complete interrupts telling me otherwise.

I've tried just about everything I can think of. Including enabling the DMA, but then no transfer complete interrupts are generated, although I think this is by design.

I double checked the Wireshark results by capturing a session with the Scarlett 2i2, here I can clearly see the feedback endpoint data arriving.

I also updated to the latest version of the CubeF4 package, no luck.

I get the feeling this is a problem with the ISO IN-transfers in general, as enabling the audio-input IN-endpoint, one that *does* gets polled every microframe, also doesn't send any data to the host.

Any help here?

[timistof]

This thead from two years ago also seems to experience the issue, although here on a 'F7

[timistof]

My hunch was that this somehow relates to the external PHY. I tried accessing the PHY's TX_BOOST register by accessing undocumented(!) registers using the code discussed in this thread, but that wasn't it.

I've turned my board into a High Speed HID device and can verify the host is now seeing IN transfers with correct data. So, the whole system is electrically capable of communicating both ways over High Speed, just not when it comes to Isochronous IN transfers so it seems.

This just *has* to be possible one way or another, or is it a limitation of the core somehow? ST, please?

I've lost just about all the hair on my head! Help!

[DV1]

Did you find a solution? If so, what was it?

I am experiencing a (different) issue and this is the only thing that I found which seems related...

In my case I have an STM32H7, configured as a MIDI device and appears to be sending data packets to the host, which never receives them. The same code on a STM32F1 board works, but I need it on the H7

[timistof]

No, sorry. Neither ST or anyone else has stepped up to provide either hints to continue or a concrete solution. I haven’t tried to get it working for another 2 years.. still like to get it working though. What is your specific problem / use case?

[DV1]

Sorry to hear that, so frustrating. It looks like nobody cares about this platform or perhaps they care just if you are a customer buying in extremely large quantities and have access to dedicated support.

My use case is https://github.com/jkominek/piano-conversion (actually a step before the final, in which MIDI would be managed in RTOS, at the moment for development/debugging I would like to have it work into the while(1) loop on a single board). I detailed a bit more on https://github.com/stm32-rs/stm32h7xx-hal/issues/405

Thanks