STM32F103 USB CDC TX Error Issue.

[seonmin]

If the Sub device is connected as below, the USB CDC TX output of the Main device does not work.

Please refer to the information below.
I don't know the reason.

[Piranha]

1. The texts are posted as an images.
2. Two of the images are repeated twice.
3. Both of the "inquiries" are the same.
4. The whole post's informational value is "something doesn't work" - basically zero value.

If you are not a developer, you cannot solve such complex problems...

[waclawek.jan]

When "doesn't work", is "main mcu" still visible in the USB Treeview on PC? Does the PC poll this mcu through USB, are there PID IN packets on the bus towards this mcu?

If both answers are yes, then it's a software problem in the mcu - debug as usually - observe the behaviour, observe the related hardware registers, trace relevant code execution paths (e.g. by toggling one or more pins), formulate hypotheses and write test code which confirms or rejects these.

JW

[seonmin]

Thank you for responding. I am a system engineer. (H/W)

※ This problem occurs intermittently. But sometimes it happens frequently.

When "doesn't work", is "main mcu" still visible in the USB Treeview on PC?
> In the PC device manager, the Com port of the main MCU is maintained.

Does the PC poll this mcu through USB, are there PID IN packets on the bus towards this mcu?
>When the PC S/W is turned on and is normal, PID IN packets come at 50us intervals. (PC S/W is simply connected to the port)
When a problem occurs, it seems that only frame sync is output at 1 ms intervals. (I'll check it again.)
However, when a problem occurs, when PC S/W outputs TX data (USB CDC RX), the main MCU receives RX data and operates normally.
And after the operation, if the response is sent through USB CDC TX, it was confirmed that it enters the buffer.
However, no data is actually sent to the PC.

[waclawek.jan]

USB is a polled bus, so if the host does not issue PID IN packets, there is no way the connected device can send data.

Why does that happen I don't know, maybe there is a USB reset at the moment the other device is connected, and while Tera Term is quite aggressive in reconnecting, maybe that fails somehow. I am just speculating here. Try capturing events on the USB bus at the moment of connection of the other device and try to decipher from there what has happened.

JW

[Piranha]

Just in case, I'll just remind that ST's parody of an USB stack works purely from interrupts. That means, if some of it's API is called from non-interrupt code or an interrupt of a different priority level than USB interrupts without properly disabling USB or all interrupts, then the code is broken. The solution is simple - toss out that broken bloatware and take something, that is developed by competent developers, like TinyUSB.

[MWB_CHa]

Hi @seonmin ,

You can provide us some more information to help understand the issue:

1. What is the firmware you used as starting point ? STM32 CubeFW ? which version ? and which tool version (ie. STM32CubeMX, STM32CubeIDE..)
2. What else in your program is running and using STM32 resources ? (other than USB CDC) are there other interrupts or threads ? Are you able to isolate the USB CDC code alone to make sure there is no interference?
3.  Are you able to record a USB trace of the communication when the issue occurs ? (using a USB HW probe or a USB software probe)
   
   Post edited to adhere community guidelines.