Posted on September 27, 2015 at 01:17Hey all,
I don't know if others have experienced this or not, since google did not turn up any good answers.
I'm running openstm32 on Win 7 pro, on a brand new machine I got. My target is the F446 Nucleo board, and it seems like the VCP drivers and my new computer are not playing nicely.
I've got ST-Link upgraded to M11 (The latest firmware), and the target is running a basic blink program that utilizes a blocking loop, and a blocking implementation of the printf over UART.
This setup has worked nicely on my previous PC, but when I migrated my project over to the new machine I get lots of weird behavior.
Here's what I see:
puTTY never prints my periodic statements for more than a minute, before acting like nothing is coming in from the UART at all. This happens in both debug and run modes. I can step through the program during debug, and watch puTTY miss the messages. I can even flash the device normally with the release target and watch the program run (LED still blinks), while the terminal missed the messages.
Once puTTY loses sight of the VCP, the target can still be re-flashed, but the com connection is not renewed. To get the port back, I have to go to the device manager and ''disable'' and then ''enable'' the COM4 port, and sometimes the messages start appearing in puTTY immediately afterwards. This only works some of the time. Alternatively, the device can be re-flashed and sometimes the connection comes back. Maybe 2/5 times.
Contrary to all the behavior seen above, I have also seen the target freeze up for whatever reason. I know this because of the solid LED being left on or off.
What's with this anyways? I'm using the same drivers as my other machine did. They are both Dells of the same family, so they should have started with very similar device drivers to begin with.
Why would Windows fail to maintain a connection? Has anyone else seen such fickle behavior? I've re-installed these drivers 10 times now, and I still can't get a consistent connection. How annoying.
Anyone have any suggestions for what I ought to try next? Maybe a different UART connected an FTDI converter? I don't mind doing that, but that's defeating the purpose of this nice and clean com port connection that's already in place!
Just let me know what you think if you have an idea of what is really happening.
Thanks!
Tyler
