7 months, 1 week ago.

COM port closes after about 10 minutes connecting USB port (on Windows 32bit)

After connecting, NUCLEO-F303K8 can communicate with PC via serial COM port. However, after about 10 minutes, it cannot send/receive any commands. The COM port seems to be closed suddenly.

I found that it occurred on Windows 32bit but didn't occur on Ubuntu 64bit. And it occurred using NUCLEO-F303K8 but didn't occur using LPC1768.

I suspect the driver of NUCLEO-F303K8 for Windows 32bit has some problem.

Does anyone have any advice on solving this problem?

Question relating to:

Affordable and flexible platform to ease prototyping using a STM32F303K8T6 microcontroller.
Comment on this question

2 Answers

7 months, 1 week ago.


Thank you for reporting your problem. We don't know this kind of issue on our side.

The first thing to try is to update the FW of the ST-Link module of your Nucleo board. It is located here

If your problem persists, we would need to know more about the context.

What type of Windows32 machine are you using ?

Are you using your computer during those 10 minutes ?

Kind regards


Thank you for your reply.

I updated the FW as you said, but the problem persisted.

What type of Windows32 machine are you using ?

  • OS : Windows 7 professional 32bit
  • CPU : Intel(R) Core(TM) i5-4310U
  • RAM : 4GB

Are you using your computer during those 10 minutes ? -> No, after connecting, just wait about 10 minutes, and try to communicate via COM port.

Below is a source code that checked this problem. (Tera term or pyserial is used on my windows PC.)

include the mbed library with this snippet

#include "mbed.h"

DigitalOut myled(LED1);

int main() {

    while(1) {

        myled = 1; // LED is ON
        wait(0.2); // 200 ms
        myled = 0; // LED is OFF
        wait(1.0); // 1 sec

When my PC could not communicate with my Nucleo board, the board seemed to be still working because LED1 was blinking. After about 10 minutes connecting, my PC could not get any return.

I'd appreciate if you could give any advice again. If you want more information, please let me know.

Best regards

posted by H Watanabe 12 Aug 2017
6 months, 3 weeks ago.


The COM port driver on the host is native to Windows so there is nothing specific to the Nucleo (ST-Link) at this level. Your description shows that a lockup condition seems to happen either from time to time (race condition for instance) or after an event that happens meanwhile. The fact that it works in other contexts is not enough to conclude where resides the root cause (unfortunately), the issue is probably a conjonction of several elements in the failing context. We tried to reproduce on our side with your application on W7 64 bits and on an old 32 bits machine (but with XP), but we found no issue so far.

Just few ideas in order to allow further investigations if you can:

1. May you have a look on power scheme settings of your PC ? If a sleep mode is enterred, powering off the ST-Link (even temporarily), the wake-up sequence would need a full restart of the application (and perhaps also a restart of the Nucleo by unplugging the USB cable)

2. Is it possible to probe the Rx/Tx signal on the Nucleo, just to see if after the failure, the issue resides in the downstream or upstream ?

3. After the issue may you please check in the PC device manager (control panel-Hardware and Sound-Devices and Printers), if all devices are working well, especially the "STMicroelectronics STLink Virtual COM Port" (right click - properties - device status)

I hope this will help

Best regards


Thank you for your reply!

I checked as follows. 1. My PC did not entered to sleep mode. 2. After the issue happened, the Rx/Tx are high level. It seems Nucleo is working except COM port. 3. After the issue, I confirmed all devices are working well.

When I was debugging with the program which showed above comment, I found another issue, which probably related this issue.

After my PC sent two characters to my Nucleo via COM port, it could not send/write any more. It means that some problems happened when "PC.putc(PC.getc())" is executed if the buffer has two characters. Also I checked it using LPC1768, but there is no problem.

Is there any difference between LPC1768 and Nucleo in terms of "getc()" or "putc()"?

I would like to get any comments.

Best regards,

posted by H Watanabe 23 Aug 2017

Hello ,

I would like to point out the fact that your program is only "getting then putting" 1 character every 1.2 seconds.

Every multiple characters that are written on the computer during the 1.2 seconds of wait functions will be discarded, except the last one.

I don't have an NXP board so I won't be able to test it, but reading the code serial_api.c for LPCxx platform does not look like it can have a different behaviour

posted by Armelle DubocST 25 Aug 2017

To post an answer, please log in.