AnsweredAssumed Answered

Serial Port to PC Hangs on Nucleo STM32F303RE after COM LED flashes

Question asked by David Peale on Aug 11, 2017
Latest reply on Aug 13, 2017 by Clive One



I am working with a Nucleo STM32F303RE board  MB1136 rev C on a Windows-7 Dell Latitude E5450 PC.  I have programmed USART2 using CubeMX, SW4STM32 IDE, and the HAL_USART_Transmit() function to simply send a number out the TX line to the PC via the virtual com port.  The ST-link driver is Rev 2.1.  Once the Nucleo is programmed, if I boot the PC with the USB cable connected to the nucleo board, the target chip runs as it should, and serial data comes into puTTY on the PC just fine for about 5 minutes and 12 seconds. At that point the COM LED on the nucleo board flashes (green and red) briefly, and puTTY stops receiving data.  The target chip is still running, and still transmitting serial data; I can see that on a 'scope via connector_3 pin .RX, but the data doesn't get into the PC any more.  Now, if I disconnect the USB cable and let Windows de-allocate com6 (the STMicro virtual serial port), I can plug the USB cable back in and com6 will show up again (as it should), the board starts running again, and a new puTTY session shows serial data coming into the PC from the nucleo.  However, about 15:45 min:sec later, the com LED on the nucleo board flashes briefly again, and once again the serial data stops coming into puTTY.  No other programs are running on my PC, and it is not going into power save or sleep modes or checking e-mail etc...  Closing the old puTTY session and opening a new one does not restore the data flow either.


Here is the relevant section of code from my main.c file showing the HAL_USART_transmit() call.


int main(void)




       char TXBuf[16];

       char RXBuf[16];

       uint16_t ADelay = 0;       // msec delay timer use

       int16_t i=0;

       int16_t j=0;

       int16_t length;

       int16_t direction = 1;     // motor direction and STOP control.  1 = CW, -1 = CCW, 0 = stop.

       double duty1 = 50;

       double duty2 = 50;

       double duty3 = 50;;

       double S1 = 0;

       double S2 = 0;

       double S3 = 0;                    // duty cycle and Sin() values for the three phases

       HAL_StatusTypeDef Status = 0;            //return value e.g. for USART


  /* USER CODE END 1 */


  /* MCU Configuration----------------------------------------------------------*/


  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */



  /* USER CODE BEGIN Init */


  /* USER CODE END Init */


  /* Configure the system clock */



  /* USER CODE BEGIN SysInit */


  /* USER CODE END SysInit */


  /* Initialize all configured peripherals */






  HAL_TIM_PWM_Start( &htim1, TIM_CHANNEL_1);           // start PWM CH1, CH2, CH3

  HAL_TIM_PWM_Start( &htim1, TIM_CHANNEL_2);

  HAL_TIM_PWM_Start( &htim1, TIM_CHANNEL_3);


  strcpy(TXBuf, "test 12345\n\r");              // default string to transmit

  length = 12;                                         // default string length

  i = 0;                                        // initialize the loop counters

  j = 0;

  /* USER CODE END 2 */


  /* Infinite loop */


  while (1)





       j += 1;

       sprintf(TXBuf, "%d\n\r", j);

       length = strlen(TXBuf);

       Status = HAL_UART_Transmit(&huart2, (uint8_t*) TXBuf, length, 9000); // test send something


       HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET);           // LED on board ON

       HAL_Delay(Status);                       // show on 'scope the return result value

       HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_RESET);  // ON and OFF gives ~250 nsec pulse




  /* USER CODE END 3 */




I don’t think the problem is an issue in my code because I can see on the ‘scope that the USART is still sending data, and the bitstream data on the scope is still counting up as it should.  So the problem appears to be somewhere in the link between the ST-Link MCU on the nucleo board and the PC’s serial port.  The serial link only fails after the COM LED indicates activity on the USB line.  I’m wondering if perhaps there is an issue in the ST-Link driver that forgets to re-enable the virtual com port functionality after the USB activity? I have tried just closing puTTY and restarting a new puTTY session, and that alone does not restore the data flow.  I have to reset the com port by (closing puTTY), unplugging the USB cable and plugging it back in (and opening a new puTTY session).


Can anybody tell me:

  1. a) what is the ST-Link USB activity that happens after 5 to 15 minutes, and
  2. b) why the virtual com port serial operation then hangs after the activity on the USB link (as seen by the COM LED flashing green and red briefly)?


Thanks in advance.