stm32_fsdev isochronous support

[leptun]

Operating System

Windows 10

Board

stm32g474nucleo

Firmware

I was using the uac2_headset example code. I tried using it on a stm32g474nucleo board, but any mcu which uses stm32_fsdev should have this issue. commit cadfcd153e8fce804f38f0e19997c13bf6931a49

What happened ?

An assert is hit at runtime:

dcd_edpt_open 760: ASSERT FAILED

Which basically says that isochronous mode is not implemented in the stm32_fsdev driver.

Is there any interest in implementing the isochronous mode in this driver? Right now the audio class can't work on a large portion of the stm32 devices (basically the cheaper ones, where OTG is not present). I imagine there might be more classes that use this endpoint mode, but this was the only class I needed at the moment. I wish I was able to switch to an f4 mcu (dwc2 driver), but with the current chip shortage, that is not possible. If there is no plan to make isochronous mode work, can there be a note added to these devices so that examples with unimplemented features are not built?

How to reproduce ?

Just run any of the examples which use isochronous transfers on the stm32_fsdev driver. Easiest board to test with might be a blue pill or similar. nucleo g4 boards with a USB shield also work. In my setup I'm using a X-NUCLEO-USBPDM1 TypeC power delivery shield which also connects the data lines to the usb port.

Debug Log

log_iso.txt

Screenshots

No response

[vorosj]

Thank you very much for the fast reply.

[vorosj]

I did a quick test: downloaded your AIOC and TinyUSB code, and compiled it in STM32CubeIDE. Success, no errors. Unfortunately I have no STM32F302, so I blindly uploaded the firmware to a STM32F303CCT6. It enumerated as mono speaker and mic, plus serial port. Wow, this uC-s has to be very similar... :-) No sound output on PA4, the pin is floating - probably the chip is different here. Also checked the Led outputs, 36MHz signal on one of them. Next I try to port the code to the 303, figure out what is different. Thank you very much for the great work.

[skuep]

Cool! Yeah, I think those MCUs are similar enough :-) It is mainly a question of the USB peripheral. But as long as it is this USB-CAN combined peripheral with at least 512 Bytes of Packet-Memory-Buffer, it should work. Can you try changing the MCU type to your STM32F303 type? (And check that a new define is set in the project settings). Maybe that it is already enough so that a different device header file is used during compilation.

Did you try the microphone input (which in the AIOC hardware really is a line-level input).

Btw, did you connect the AIOC to a Windows PC? That would mean that at least the USB part is working on Windows. I have only tested it on Linux so far, because I completely removed Windows from my Computers some years ago.

Ah, also I did not yet push the changes I announced a few posts earlier regarding the buffer-underflow prevention. I will test it some more and push it today in the evening.

Btw, I have since implemented the buffer-creep prevention as dictated by the USB spec.

[vorosj]

Btw, did you connect the AIOC to a Windows PC? Sure, it enumerated as mono mic, speaker and serial port. When I plug in the usb, win11 selects it as audio output, and silence. If I select the audio output to the normal and back to the uC, it's always working. However no sound on PA4, probably there is a difference in the DAC peripheral. The absolute bare metal DAC init is a bit steep for me :-), I usually use CubeMX for the job. I touched the pins to check if it's working as mic, no response. It was just a short unreliable trial, so not sure if there is difference too, or just missed the input pin.

In order to port the code to the 303, I first started DAC with DMA in a new empty project. CubeMX generated me a faulty code. It initiated the DMA and the DAC in the wrong order, set a register in the DAC before it has clock. Takes me several hours to figure out, but now works. However, at first look no need for DMA in your project, so dont't know why I bother with it...

I don't yet learnt the code in details, not sure how the in and out audio stream keep sync. I am not familiar with the usb standards, not even know if the device itself has to sync to the stream, or send feedback to the PC and the PC side is responsible for the sync.

My project is amplitude modulated signal for an old tube radio. :-) Not too much broadcast are still working in the 0.5...1.5MHz band, and I like old radios. USB sound stream -> AM signal transforms the old radio to netradio, of course without any mod on the radio side.

The job is harder then I estimated, because the controllers I have either not working with usb audio class (CubeMX code is broken, TinyUSB audio class missing for fsdev), or no DAC in the uC. USB is complicated. I don't even know what fsdev and dcw2 are. Why - for example - the STM32F103 has fsdev and not working, but the very similar GD32VF103 has dcw2 and working?

My first succesful effort was an F411, it works with the CubeMX generated code, and with TinyUSB as well. But no DA. I tried PWM, it's working well, but filtering out the 48kHz sampling freq requires steep filter, and I like to keep it as simple as possible. Of course it's for fun, challenge accepted, I want to solve it without steep active analog filter in the audio part. :-)

[PanRe]

Up to my knowlegde, dcw2 is intended to fuse all the device drivers of the individuel MCUs together. This, however, is work in progress and unfortunately bugs fixed in dwc2 may not be fixed in the individual drivers and vice versa. I think the docs should be improved to inform everybody of its purpose...

The audio class works fine so far, most bugs reported regarding audio concern the ISO EP support in the device drivers. The same holds true for fsdev.

I am happy there is progress for the 103 and 303 devices! It would be cool if the driver would become mature enough for a PR! :)

[Iktek]

In order to port the code to the 303, I first started DAC with DMA in a new empty project. CubeMX generated me a faulty code. It initiated the DMA and the DAC in the wrong order, set a register in the DAC before it has clock. Takes me several hours to figure out, but now works. However, at first look no need for DMA in your project, so dont't know why I bother with it...

Just FYI: I also use CubeMX and had this issue. I posted it to the forum and it should be fixed in the current CubeMX releases. Nevertheless if you're using an "old" ioc file you should manually edit the order of the Init functions with is coded in a human readable form.

Up to my knowlegde, dcw2 is intended to fuse all the device drivers of the individuel MCUs together. This, however, is work in progress and unfortunately bugs fixed in dwc2 may not be fixed in the individual drivers and vice versa. I think the docs should be improved to inform everybody of its purpose...

IMHO it's more a point of which IP-Core is used in the Product. So a few products of ST use the "fsdev" core of ST. Other Products use the DWC2 core which is a bought in core of DesignWare. So as long as u use a chip which has the "fsdev" core and it's register set implemented, the driver should work. For STM32L4xx devices you need to use dwc2 driver.

Regards Pascal

[skuep]

In order to port the code to the 303, I first started DAC with DMA in a new empty project. CubeMX generated me a faulty code. It initiated the DMA and the DAC in the wrong order, set a register in the DAC before it has clock. Takes me several hours to figure out, but now works. However, at first look no need for DMA in your project, so dont't know why I bother with it...

I would just load the STM32CubeIDE project from my AIOC repository. Then go into project settings and change the MCU to the STM32F303 instead of 302. Hit compile again and try the code. It is well possible that this might already be enough to get it working. There is no need for DMA in my project. There would be no real benefit here. Note that it might still be possible that there is a problem with Windows compatibility, that I have not yet found.

The job is harder then I estimated, because the controllers I have either not working with usb audio class (CubeMX code is broken, TinyUSB audio class missing for fsdev), or no DAC in the uC. USB is complicated.

I hear you. I thought my project would be a fun little project.. since I found out that there is basically no existing way to make a USB class device. Since then most of the work was getting my head around the USB audio spe and implementation specifics.

I am happy there is progress for the 103 and 303 devices! It would be cool if the driver would become mature enough for a PR! :)

At least SOME progress 😃. Some stuff is still not quite up to standard I would say, like the manual endpoint mapping. Also some things I have modified and changed and these changes need to be tested against other tinyusb classes. You know where to find my branch if you want to have a go at testing or developing.

[vorosj]

I would just load the STM32CubeIDE project from my AIOC repository. Then go into project settings and change the MCU to the STM32F303 instead of 302. Hit compile again and try the code.

It compiled without errors for STM32F303CC. Enumeration on win11: mono speaker, mic (TinyUSB Device), serial port The serial port is working.(tested using putty terminal and scope)

It's possible to select it from win11 as sound otput, volume control works (except no sound). No sound from the DAC tested by scope, stable low state on PA4. The mic is not working (just touched the pin in mic test mode). Led pins: B9 high, B8 1msec pulses, 50% or 95% high pulse stream, not sure why one or the other, doesn't change if I select/deselect the board as sound output

Considering it enumerates and the serial port is working, the main USB functions are working. Next I debug it, check if the buffer filled, the DAC register loaded with data etc.

Thank you very much for help.

I am HAM, HA6TI, and often use FT8 mode on my Xiegu G90. I have a xgcomm USB-digimode-3 interface, it's basically an usb soundcard, no serial port, so no built-in CAT control. It has a high bit adc/dac, but it's probably not important, as FT8 is not sensitive. I am sure your AIOC could do the job, plus CAT. :-) The xgcomm is isolated, it's important because the possible strong EM radiation.

[vorosj]

Forgot to mention, in device manager/sound, video etc device configured (usbaudio2.inf) device started (usbaudio2)

[vorosj]

Debugging captured my mistake immediately... :-) I started the program in debug mode, then plugged in the USB cable. It enumerated. When I touched the volume control on the PC, debugging stopped, TU_Assert Isochronous not supperted yet. It means I copied the official Tinyusb into your AIOC project instead of your mod. (I downloaded it in .zip format, this way without the linked TinyUSB). I cloned it using git, it's working. :-)

Thank you for the great work and help. This way my project is almost ready, just have to start a free timer for the carrier signal, a simple hw AM modulator, RF filter, and ready.

[skuep]

It compiled without errors for STM32F303CC. Enumeration on win11: mono speaker, mic (TinyUSB Device), serial port The serial port is working.(tested using putty terminal and scope)

Nice! you can also theoretically wire those pins in loopback configuration to test it.

I am HAM, HA6TI, and often use FT8 mode on my Xiegu G90. I have a xgcomm USB-digimode-3 interface, it's basically an usb soundcard, no serial port, so no built-in CAT control. It has a high bit adc/dac, but it's probably not important, as FT8 is not sensitive. I am sure your AIOC could do the job, plus CAT. :-) The xgcomm is isolated, it's important because the possible strong EM radiation.

Very cool. Theoretically you could also use the serial interface for CAT right? Right now the AIOC is supposed to be for HTs only and the serial is for programming it. Yeah, the AIOC does not have isolation, because I would think it is not required for an HT. Might be different for a bigger rig.

Out of interest: Is there any standardized or at least widely-used connector? It might be worthwhile to fork the k1-aioc PCB (has K1 connector) and modify the solder pads to solder on a DIN connector (or whatever is used). The firmware would be the same :-)

I started the program in debug mode, then plugged in the USB cable. It enumerated. When I touched the volume control on the PC, debugging stopped, TU_Assert Isochronous not supperted yet. It means I copied the official Tinyusb into your AIOC project instead of your mod. (I downloaded it in .zip format, this way without the linked TinyUSB). I cloned it using git, it's working. :-)

Nice! I think the best way is to clone the AIOC project and then run a git submodule update --init --recursive and it will pull the correct TinyUSB fork automatically.

Thank you for the great work and help. This way my project is almost ready, just have to start a free timer for the carrier signal, a simple hw AM modulator, RF filter, and ready.

No worries, I am glad it is working well. Is it still throwing the assertion? I remember enabling the ISOCHRONOUS stuff only for a few hand-picked STM32 types here: https://github.com/skuep/tinyusb/blob/0.14.0-sk/src/portable/st/stm32_fsdev/dcd_stm32_fsdev_pvt_st.h. Look for #define ISOCHRONOUS_DOUBLEBUFFER. However as far as I can tell, the STM32F303CC is included.

[vorosj]

Is it still throwing the assertion?

No, it's working in debug mode with connected jlink too.

[vorosj]

Out of interest: Is there any standardized or at least widely-used connector?

AFAIK no. My rig has a 3.5 stereo Jack for serial communication (CAT and fw update), and a 8 pin mini Din for audio IO (for fans of contact failure).

[HiFiPhile]

@skuep Hi, I made some commits based on your fork, which includes:

• Rebased on master
• Minor fixes
• Reworked FIFO based transfer
• Added an endpoint allocator

I've tested with my CDC & HID composite device (mine FIFO enabled CDC class fork), could you test with your UAC enabled project ? Especially if endpoint alloc/free goes well, you can also modify UAC class to enable FIFO based transfer.

https://github.com/HiFiPhile/tinyusb/tree/0.14.0-sk

[skuep]

Cool! I will have a look tomorrow 😊

[HiFiPhile]

For anyone who is interested, PR is up #1828, including a new example audio_test_multi_rate to demonstrate multi-format support.

My test is done on STM32L072, any feedback is welcome.

[skuep]

Very nice! I did not yet get around to testing your branch unfortunately.

Funnily enough, I am also currently working on getting multirate to work in my AIOC project 😃. I ran into problems where Microphone and speaker use the same clock. Will definitely have a look into your code.

Thanks a bunch!

[hathach]

implemented by #1828