AnsweredAssumed Answered

Problem with UART on NUCLEO-F302R8 when sending exactly 14 characters

Question asked by b.r on Oct 23, 2015
Latest reply on Oct 23, 2015 by b.r
I have a strange problem with my serial communication using UART2 on the NUCLEO-F302R8 demo-board. I have successfully used this demo-board in a previous project in which serial communication was used in the same way. I recently found out that it can behave unpredictable when sending exactly 14 characters using the HAL libray function HAL_UART_Transmit(), to send serial data to the PC in blocking mode.

I generated project code using the STM32CubeMX for MDK-ARM V5. The main looks as follows:

01./* Infinite loop */
02./* USER CODE BEGIN WHILE */
03.char txBuffer[64] = { 0 };
04.while (1)
05.{
06./* USER CODE END WHILE */
07. 
08. /* USER CODE BEGIN 3 */
09.  
10.       sprintf(txBuffer, "12345678901234");
11.       HAL_StatusTypeDef serialStatus = HAL_UART_Transmit(huartx, (uint8_t*)txBuffer, 14,3000);
12.       HAL_Delay(100);
13. }
14./* USER CODE END 3 */

I found that when the Size value of the HAL_UART_Transmit() function is exactly 14, it send the data out irregularity, with sometimes several seconds before a large block of new data shows up in hyperterminal. If I change the Size value to anything other than 14 it send the data out in a fluent manner.

My UART init looks as follows (generated by CubeMX):

01./* USART2 init function */
02.void MX_USART2_UART_Init(void)
03.{
04. 
05.  huart2.Instance = USART2;
06.  huart2.Init.BaudRate = 921600;
07.  huart2.Init.WordLength = UART_WORDLENGTH_8B;
08.  huart2.Init.StopBits = UART_STOPBITS_1;
09.  huart2.Init.Parity = UART_PARITY_NONE;
10.  huart2.Init.Mode = UART_MODE_TX_RX;
11.  huart2.Init.HwFlowCtl = UART_HWCONTROL_NONE;
12.  huart2.Init.OverSampling = UART_OVERSAMPLING_16;
13.  huart2.Init.OneBitSampling = UART_ONEBIT_SAMPLING_DISABLED ;
14.  huart2.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;
15.  HAL_UART_Init(&huart2);
16. 
17.}

The serial data is received using the USB CDC provided on the demo-board (STLink virtual COM port). 

I tried the following things to see where the problem is:
-Change the baudrate, when I use 9600 this problem is less eminent. 
-Change oscillator configuration from HSI to HSE, using the bypass clock on the board
-Stepping through the code using the debugger: does not show any error status, send out data normally in this case (but slow due to stepping)
-Sending data using interrupt mode, same issue
-Other terminal program (Tera term) shows the same issue

I hope you can help me out with this issue!

Outcomes