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

[David Peale]

Posted on August 11, 2017 at 20:05

Hello,

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)

{

  /* USER CODE BEGIN 1 */

       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. */

  HAL_Init();

  /* USER CODE BEGIN Init */

  /* USER CODE END Init */

  /* Configure the system clock */

  SystemClock_Config();

  /* USER CODE BEGIN SysInit */

  /* USER CODE END SysInit */

  /* Initialize all configured peripherals */

  MX_GPIO_Init();

  MX_TIM1_Init();

  MX_USART2_UART_Init();

  /* USER CODE BEGIN 2 */

  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)

  {

  /* USER CODE BEGIN 3 */

       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

       HAL_Delay(100);

  }

  /* 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.

#serial-port #nucleo #uart #usart #nucleo-f303re

[Tesla DeLorean]

Posted on August 11, 2017 at 21:36

Would recommend pulling current ST-LINK Utilities, making sure firmware is up to date.

Really not had any USART/VCP issues with the NUCLEO/DISCO boards supporting such, on Win7 x64 boxes

Make sure 'Status' has some bounded value, so you're not waiting a millenia..

[David Peale]

Posted on August 12, 2017 at 04:49

Thanks for those suggestions. 

I haven't had trouble with Status returning large values that produce large delays.  Values seem to run from 0 to 4 (0 to 3 are enumerated in the typedef, 4 is not...)

Further investigation of the problem shows that when the COM LED flashes, the 303RE MCU is _reset_ and my program starts counting from the beginning again.  So The loss of serial port appears to be because the serial port has been reset as well.  I'm not sure why the data flow isn't re-established by just restarting puTTY, but apparently Windows needs a new reference to fully reset the port before data flows again.  Oddly, the RX side of the channel does not seem to be affected.  I can transmit data _to_ the mcu, but not from it.  Any ideas?

[David Peale]

Posted on August 13, 2017 at 05:39

Another thought: I recall now that the Nucleo board as delivered showed a similar problem of resetting after some idle time (e.g. ~ 15 minutes). If you take that stock nucleo -303RE board running the flashing LED firmware that it comes with, you can click on the user button to change the flash interval. So I recall that if I changed the flash interval and then left it alone for some time, I would come back to it and the flash interval would have returned to the original flash interval. I recall thinking that was odd, but I didn’t think too much of it at the time. That is consistent with what I am seeing in my board behavior now, i.e. the board resets itself after the COM LED flashes for some reason. So my question is really coming around to: why does the COM LED flash after 5 to 15 minutes of idle activity, and why does this reset the MCU and the serial port?

Thanks in advance…

________________ Attachments : image001.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyW7&d=%2Fa%2F0X0000000b8x%2FKOfc.SdSBAUmC2Gfav8VPRtPJ_AiqGm8o4EWFZLdwv0&asPdf=false

[David Peale]

Posted on August 13, 2017 at 08:00

Hi Again,

I have another clue as to what the problem may be. The Nucleo board mounts a portion of the ST-Link MCU flash as a removable storage disk drive. The periodic COM LED flashing that hangs the -303RE MCU TX virtual com port serial function appears to be related to the process of mounting that “drive�?.

You can verify this by disconnecting the USB cable to the board. Then connect it to start the board. The COM LED will light up solid red. Windows will bring up an “AUTOPLAY�? window asking if you want to open NODE_F303RE (

:)

). I close (X-out) this window. Then go My Computer and “eject�? this Removable Storage Device. It will dismount and disappear from the My Computer window. Now wait ~ 15 minutes. On my system, when the COM LED flashes red and green (staying solid green in the end) on the Nucleo board, it appears to be because the NODE_F303RE is getting mounted again as a removable storage device (drive D: on my system), and simultaneously the TX serial function hangs, and the 303 MCU is reset.

Regards,

David

________________ Attachments : image001.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyHA&d=%2Fa%2F0X0000000b8u%2F.NCy6RHVssknMsITiGZcWoZvoVIXTFEuXWEWbVlyNSw&asPdf=false

[Tesla DeLorean]

Posted on August 13, 2017 at 14:47

A DELL, check the filter drivers probably some Intel storage driver interfering with mbed MSC. Search forum, issue covered will look when at PC

[Tesla DeLorean]

Posted on August 13, 2017 at 15:14

https://community.st.com/0D70X000006T0l9SAC