Cannot get past SET LINE CODING request with CDC example on stm32l083cz

[jelledevleeschouwer]

Hi,

First of all I would like to thank you for all the effort on this cool project.

I have some difficulties myself getting the simple CDC_MSC example to work (without the MSC part) on a custom board equipped with an stm32l083cz. The USB device enumerates as /dev/ttyACM0 but when I open it using cat or minicom, it produces all garbage:

$ cat /dev/ttyACM0
1
lhhhhhwwww
$

However, while the device produces this garbage on the host machine, I don't receive any USB interrupts anymore (I set a breakpoint in USB_IRQHandler).

I took a wireshark capture and can't seem to get past the SET LINE CODING request (cannot seem to upload pcapng files on Github it seems, so I added the .txt extension 😓): usb_enumeration.pcapng.txt. The tinyUSB logging seems to say the same: usb_enumeration_tusb_log.txt.

Has anybody ever experienced anything like this? The device enumeration seems OK, but communication does not seem to work. The thing is also that I don't see any requests from the host to the device anymore. Is there maybe something in the enumeration that causes the host to do that? While the CDC_ACM driver still seems to produce data and I am not getting interrupts on the device, the issue seem more likely to be related to host instead of the device, or am I wrong?

Any clues?

Thanks in advance,
Best regards,
Jelle

[HiFiPhile]

Hum that's strange...
I'm using stm32l072 they should be quite similar. Have you modified something ?

[jelledevleeschouwer]

Hi @HiFiPhile, thanks for your swift reply!

I just reverted back to STM32 USB device library (which worked fine previously) and the issue persists, so I am starting to find my host machine suspicious. The thing is, my user has always been a member of the dialout group so normally I don't suspect that I have to have root permissions to acces /dev/ttyACM0 and suddenly I do? Strange... I am going to reboot my machine and retry.

I'll let you know in a minute or 10.

[jelledevleeschouwer]

Ha!

It did indeed seem to be related to my host machine most probably. After reboot, the log from above continues with:

USBD Setup Received 21 22 03 00 00 00 00 00
  CDC control request
  Queue EP 80 with 0 bytes ...
USBD Xfer Complete on EP 80 with 0 bytes
  Set Control Line State: DTR = 1, RTS = 1

USBD Setup Received 21 20 00 00 00 00 07 00
  CDC control request
  Set Line Coding
  Queue EP 00 with 7 bytes ...
USBD Xfer Complete on EP 00 with 7 bytes
  0000:  00 C2 01 00 00 00 08                             |.......|
  CDC control complete
  Queue EP 80 with 0 bytes ...
USBD Xfer Complete on EP 80 with 0 bytes
USBD Xfer Complete on EP 02 with 1 bytes
  CDC xfer callback
  Queue EP 02 with <vApplicationStackOverflowHook(pxTask=0x20003b7c <cdc_taskdef>, pcTaskName=0x20003bb0 <cdc_taskdef+52> "cdc"> called here>

So still not there yet, but we're making progress. @HiFiPhile, my apologies if I have wasted some of your time. And thanks for looking into it.

Another question (maybe for a different discussion), but is there any documentation available about reducing the memory fooprint of the stack? We're currently quite low on RAM so I wonder if we could reduce the footprint of tinyUSB even further? For example, can the cdc_task be eliminated altogether by making used of the callbacks from the tusb task instead?

[HiFiPhile]

For example, can the cdc_task be eliminated altogether by making used of the callbacks from the tusb task instead?

Yes cdc_task is just an example.

You can change the buffer size in tusb_config.h, but in this example they are already the smallest value.

tinyusb/examples/device/cdc_msc_freertos/src/tusb_config.h

Line 106 in 9c3fdb8

#define CFG_TUD_CDC_RX_BUFSIZE (TUD_OPT_HIGH_SPEED ? 512 : 64)