Virtual Com Port Loopback runs w/o debugger not w/ debugger

[steve1]

Posted on September 26, 2013 at 18:01

Greetings,

I've brought up the ST example VirtualComPort_Loopback (V4.0.0) on a Keil demo board (MCBSTM32E vers3) and the Keil enviroment (uVision 4.71.2.0) connecting through the ST virtual comport driver (1.3.1.0)  and it works fine when not run from within the debugger.  When run from within the debugger, however, the terminal emulator (PuTTY) error's out with: ''Unable to open connection to Com46, Unable to configure serial port''.  The Com port (46) does show up in device manager and no errors are indicated.My uneducated guess is that the ST virtual comport driver is not happy something that's different in it's interaction over the USB connection when the debugger is running and it's refusing the terminal emulators connection.I would really appreciate any ideas for chasing this problem down as the problem also exists on a custom board with a complex application in need of enhancing and debugging...Thanks in advance.Steve.

[steve1]

Posted on December 04, 2013 at 19:58Follow-up (may be useful for others with this problem):  The best I could do for a solution was to create different build targets for stand-alone vs debugger differentiated by a #define and #ifdefs in the code.  The stand-alone version used the USB port as the applications console when running without the debugger.  When running with the debugger, the application's console was re-directed to the ITM port and accessed by the debuggers ''printf'' window.In other words, I was unable to find a way to run the debugger that didn't kill the USB virtual terminal connection.As an aside, though I posted my question on both the Keil and ST forums, I did not get any replies on either.  <sniff..., was it something I said?>Steve.

[Tesla DeLorean]

Posted on December 04, 2013 at 20:37

My experience is with the VCP implementations are for F2 and F4 chips, using the V2.1.0 tree

STM32_USB-Host-Device_Lib_V2.1.0\Project\USB_Device_Examples\VCP While there is some porting effort to use on non-EVAL series boards, I don't recall seeing any code that would preclude operation on a debugger, beyond the issue of timeliness if you breakpoint or single step stuff. Not sure I can offer any perspective on F1 designs using V4.0.0, or the Keil board, which is why I didn't respond to the original posting.