[CDC] Serial USB without DTR

[jlocsx]

Is your feature request/improvement related to a problem? Please describe.

I recently experienced the following issue using the Blue Pill board (STM32F103C8T6 MCU) with the STM32Duino core:

• Using the USB CDC, the data sent by Blue Pill was not received by an old Terminal Serial written via Delphi 7;
• For example, this Terminal was unable to receive data from a program based on the following code:
  • https://gist.github.com/jlocsx/f01631e6109fff5e485fbd998b28a8cf

This is because the DTR signal is not enabled by default on that Serial Terminal. After enabling this signal, I was able to receive the data without any problem.

But I didn't experience any issue when I performed the tests using a Rust program based on the following code with the Blue Pill:

• https://github.com/stm32-rs/stm32-usbd-examples/blob/master/example-stm32f103c8/src/main.rs

I also tested a Honeywell RFID reader (YJ-HF500) that communicate via USB CDC, and the Terminal was able to receive the data even with the DTR signal disabled.

Describe the solution you'd like

I found the following "work around" in the STM32duino forum:

• https://www.stm32duino.com/viewtopic.php?f=62&t=461

But I would like something that can be configured through the development environment, without having to modify the usbd_cdc_if.c file directly.

For example, I would like to be able to enable/ disable the DTR signal verification by overwriting some macro. Or is this already possible?

[fpistm]

Hi @jlocsx
do not hesitate to provide a PR for this as mentioned in the forum any contribution are welcome. 😉

[maxgerhardt]

This issue just hit me (and other guy), too. I was using hterm and miniterm.py (serial monitor in PlatformIO) as my serial monitor programs and saw no output -- believing that something was seriously broken. Then I found this issue and activated the DTR line, and in that moment output came through again.

What was the rationale behind the change? Per above two widely used serial monitors don't set the DTR flow control lines upon opening the virtual COM port, leading to this strange behavior.

[ag88]

hi for those using Linux there is one thing to check

• create a udev rules file e.g.
  /etc/udev/rules.d/45-stm32duino.rules
  add a line like

ATTRS{idProduct}=="5740", ATTRS{idVendor}=="0483", MODE="664", GROUP="plugdev" SYMLINK+="stm32duino" ENV{ID_MM_DEVICE_IGNORE}="1"

make sure that the product id and vendor id matches that used in your sketch.

the main thing is that
ENV{ID_MM_DEVICE_IGNORE}="1"
which tells udev not to treat it as a modem
that issue is explored in this thread
https://www.stm32duino.com/viewtopic.php?f=62&t=1000

[fpistm]

which tells udev not to treat it as a modem

I though it was fixed by #884

[ag88]

hi fpistm,
fix #884 is useful and necessary.
but this that Serial stalling at the beginning in Linux is a Linux problem. not a USB CDC nor stm32duino problem.
Linux tries to initialize the comm ports as a modem if it see a USB CDC ACM connected.
in particular where a 'modem manager' or some linux based s/w (udev?) tries to initialize the port
i think i would help to add this in the wiki somewhere.
we should probably add these to the 'faq' / or frequently encountered problems

there could be 'old' linux distributions which requires users to tell udev that 'it is not a modem' i.e. edit the udev rules file
edit: added here
https://github.com/stm32duino/wiki/wiki/FAQ#usb-serial-cdc-stalls-initially-and-connecting-using-a-serial-monitor-fails

[fpistm]

Hi @jlocsx, @maxgerhardt and @ag88

I've made a PR to implement a way to disable the DTR usage. See #1382.
If you can test and/or have any feedback this will be welcome.

I've tested using hterm as stated by @maxgerhardt and it works as expected.

Hope it is fine for you. 😉