We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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...
I originally posted this on the ST support forum a couple of weeks ago. No replies.
Thanks in advance.
Steve.
Follow-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?>
How were you connecting the debugger to the board?
Did you compare the schematics of the Keil Board, and ST's own boards (which is, presumably, what they'd have had in mind when making their USB stuff...)
Thanks for your reply. The debugger is being run through the JTAG (20 pin on the Keil board, 10 pin on my custom board) connected through the ULINK2. The USB is identically wired on both the Keil board (which I'm running) and the equivalent ST board. ST resells the Keil board as part of their Keil starter kit offering for this processor so one would hope it would work with their demos <sigh>.
Nonetheless, the JTAG ports ARE wired a little differently (something I had not looked at till your comment). On the Keil board the 20 pin JTAG connector has pins 11, 17 and 19 open whereas on the ST board they are all tied to ground via individual 10ks.
I don't know enough about the generic JTAG interface nor the unique-to-ST features to know if this is relevant or not. I have no idea what affect these connections have on the ULINK2. However, it surely doesn't help with regard to my custom board as the 10 pin JTAG interface on the ULINK2 does not include those connections. The 10 pin JTAG also does not support the TRS signal (PB4 on both the Keil and ST demo boards).
Does this help you understand what's going on? I'm still unclear as to a means (other than what I've already done) to move forward.
Thanks again, Steve.