STM32G0B1 USB clocking

[rm5248]

I am working with am STM32G0B1CB for USB communications, using Zephyr as my OS.  I am trying to have multiple CDC ACM serial ports, so that they will show up as /dev/ttyACM0, /dev/ttyACM1... on Linux.  Everything seems to work fine if I have only one CDC ACM port, but once I add in another CDC ACM my device is no longer recognized by Linux.  Specifically it will fail with the following:

36474.549454] usb 1-2: new full-speed USB device number 10 using xhci_hcd
[36474.702429] usb 1-2: config 1 interface 1 altsetting 0 endpoint 0x82 has invalid maxpacket 512, setting to 64
[36474.702434] usb 1-2: config 1 interface 1 altsetting 0 endpoint 0x1 has invalid maxpacket 512, setting to 64
[36474.702437] usb 1-2: config 1 interface 3 altsetting 0 endpoint 0x84 has invalid maxpacket 512, setting to 64
[36474.702439] usb 1-2: config 1 interface 3 altsetting 0 endpoint 0x2 has invalid maxpacket 512, setting to 64
[36474.702980] usb 1-2: New USB device found, idVendor=2fe3, idProduct=0100, bcdDevice= 3.07
[36474.702983] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[36474.702984] usb 1-2: Product: LCC Link
[36474.702986] usb 1-2: Manufacturer: Snowball Creek
[36474.702987] usb 1-2: SerialNumber: 30325019003E001F
[36474.706171] usb 1-2: can't set config #1, error -32
[36476.405647] usb 1-2: reset full-speed USB device number 10 using xhci_hcd
[36476.761759] usb 1-2: reset full-speed USB device number 10 using xhci_hcd

My device does enumerate properly in my virtual machine where I do my development work(VMWare), so I do see two ttyACM devices.

I believe that my problem has to do with the main clock.  I have configured my clocks to be the following(USB is set to use PLLQ, not HSI48):

Even though the PLLQ is set to 48MHZ the setup does not finish correctly.  Could this be due to the relatively slow clock(8MHZ)?  If so, is there a better frequency to use for the external oscillator in order to provide good USB communication?

[AScha.3]

1. What's not finished correctly on setup?

2. Your USB works fine with one com channel, so why you think it has to do with the clock and not your program is the problem?

[gbm]

Not a single word on the USB stack used. My wild guess is incorrect config descriptor with no IADs.

For USB, the HSI48 synchronized to USB SOF is a perfectly correct clocking option.

Edit: Look at the log in the original post - the problem is diagnosed. Endpoint sizes are too big, PMA configuration will be incorrect (overflow - too much space used). reduce data in and out endpoint sizes to 64, set the notification ep size to 10 or 16 (notification ep is usually mislabeled as "command"). Verify the consistency of ep size setting in config descriptor and hardware device configuration.

[rm5248]

1. What's not finished correctly on setup?

The device fails to enumerate with error -32.  From what I've read, this is EPIPE, which means that the device did not respond back in time.

2. Your USB works fine with one com channel, so why you think it has to do with the clock and not your program is the problem?

Because if it is plugged into my computer it will not work.  If I leave it plugged in but then connect it to my VMWare virtual machine, it enumerates properly.  I believe this is because VMWare effectively has a virtual USB hub that is more tolerant of the timings.

Not a single word on the USB stack used. My wild guess is incorrect config descriptor with no IADs.

For USB, the HSI48 synchronized to USB SOF is a perfectly correct clocking option.

I mentioned I am using Zephyr, but to be explicit I am using the USB stack from Zephyr.

If I use the HSI48 I can't enumerate the device in this configuration.

reduce data in and out endpoint sizes to 64, set the notification ep size to 10 or 16 (notification ep is usually mislabeled as "command").

That is a good idea, I will try that.

[rm5248 · Accepted solution]

Upon further investigation it seems that the "invalid max packet" was a clue. It seems as though I had turned on USB high speed mode in Zephyr, which allows for a longer endpoint size as per the USB spec I believe.  However, the STM32 is full-speed only, so these endpoints were invalid.

Removing this setting from Zephyr fixed my problem, and my device now enumerates on all of the machines I have tested it on.