USB VCP - cannot open COM Port

dpfeffer9 · ‎2016-02-01

Posted on February 01, 2016 at 21:19

Hello,

I am using USB Virtual Com Port with CubeMX on a STM32F4 controller.

The problem is, that occasionally, but increasingly often I cannot open the COM Port to my Device. It is very hard to reproduce, as changes in completely different code regions can cause that behaviour.

The port is enumerated in my device manager, but the connection from a terminal program fails.

What are the possible reasons for this (ram, interrupt-interference, ...)?

Are there any general guidelines for a ''robust'' USB Virtual Com Port?

#stm32 #usb #cdc #vcp

Tesla DeLorean · ‎2016-02-01

Posted on February 01, 2016 at 22:03

USB COM ports can get into all kinds of weird states if disconnected/reconnected while open in terminal applications.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

dpfeffer9 · ‎2016-02-01

Posted on February 02, 2016 at 08:44

Well, the bad state does not occur after serveral connects and disconnects.

Directly after a hardware reset, it sometimes works and sometimes it doesn't. Sometimes a change in optimization helps (e.g. from -03 to -0s - or vice verse).

I'm desperate

re.wolff9 · ‎2016-02-02

Posted on February 02, 2016 at 10:21

It seems you have a ''difficult to debug'' problem. Something that depends on timing or code size. For example, maybe your code overflows the flash, and sometimes the code does not get called or sometimes you configuration is smaller and it does fit.

Key to finding clues as to where the problem lies is to try and make a log of what helped make it work again and what did not. That ''database'' of what helped and what not, gets contaminated with false-readings when you make stupid little mistakes like ''forgot to reset the module'', or ''forgot to upload the binary''.

One important thing is: does a version of the software always work-or-not-work? Does resetting the CPU help, or does it never make a difference?

dpfeffer9 · ‎2016-02-02

Posted on February 02, 2016 at 13:50

Thanks. I will start such a list.

At least I can have a normal debug session... Are there any possibilities to debug the changing states of the MX CDC Driver and/or HAL_PCD? I've got no deep experience with debugging USB or the HAL.

tsuneo · ‎2016-02-03

Posted on February 03, 2016 at 15:32

If your firmware would disturb USB interrupt more than 50ms, the host could fail to open the virtual COM port.

Opening COM port involves a couple of USB class-specific requests, which evoke USB interrupt on the device.

- Get_/Set_LineCoding -- baudrate, data bits, parity, stop bits

- SetControlLineState -- DTR, RTS setting

Host issues these requests with timeout, within which your firmware should respond in USB interrupt. The shortest timeout value (50ms) is assigned to SetControlLineState.

Once the COM port is successfully opened, your firmware may disturb USB interrupt much longer period. Host application may assign any (or no) timeout value to the bulk IN/OUT (TX/RX) transfers.

Tsuneo

dpfeffer9 · ‎2016-02-16

Posted on February 17, 2016 at 08:22

When I use the HAL to configure and drive my USB-CDC: How would I notice, that a PC/Host wants to conntect? I then could turn off my other interrupts/timers to make sure that there's no distraction from the sensitive connection process.

In which callback should such behaviour be implemented?