rxa1031 commented 4 years ago

Hi,

ISSUE: One less byte received by UART Receive code.

From where did I get the C and H files: I used STM32CubeMX to generate code for USART1 with 115200 8N1 full duplex communication with just three signals namely TX, RX and Ground.

Only TX looks Good: I was able to send out data as expected with Interrupt based UART transmit command.

Observed that Receive along with Transmit has issues I observed later while testing the Receive implementation that one less byte was received.

Setup for testing For this testing, I shorting the TX and RX pins on the DB9 connector (CN2 of STM32H743I-EVAL board), so that the data that is transmitted out is received back by the microcontroller.

Analysis

On further analysis when sending just the data out from my Laptop and the EVAL board receiving the data, I still observed the code in file STM32H7XX_HAL_UART.C causing receive issues.
I observe HAL_UART_IRQHandler() being called only once. Thus the call to huart->RxISR(huart) is made only once. In reality two calls should be observed. I did this check with help of a counter variable and not by using a breakpoint.
It looks like the FULL DUPLEX Asynchronous Tx and Rx implementation is missing. The state HAL_UART_STATE_BUSY_TX_RX is never used and TxRxCpltCallback() is also unavailable. I believe that it is probably good that TxRxCpltCallback() is missing, but definitely a function like HAL_UART_TransmitReceive_IT() is definitely needed along with separate existing callbacks for Tx Complete and Rx Complete.

Sharing code part that I added to file main.c


void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
//  if(huart->Instance == USART1)
    {
        bIsAsyncUSART1ReceiveComplete = 1;
    }
}```

```int main(void)
{
...
  while (1)
  {
        bIsAsyncUSART1ReceiveComplete = 0;

        HAL_UART_Receive_IT(&huart1, (uint8_t *)RS485_Rx_Data, 2);

        while(!bIsAsyncUSART1ReceiveComplete);

__nop();
__nop(); // to place break point to confirm that the two bytes that I sent from my laptop were received
  }
}


  * @brief USART1 Initialization Function
  * @param None
  * @retval None
  */
static void MX_USART1_UART_Init(void)
{

  /* USER CODE BEGIN USART1_Init 0 */

  /* USER CODE END USART1_Init 0 */

  /* USER CODE BEGIN USART1_Init 1 */

  /* USER CODE END USART1_Init 1 */
  huart1.Instance = USART1;
  huart1.Init.BaudRate = 115200;
  huart1.Init.WordLength = UART_WORDLENGTH_8B;
  huart1.Init.StopBits = UART_STOPBITS_1;
  huart1.Init.Parity = UART_PARITY_NONE;
  huart1.Init.Mode = UART_MODE_TX_RX;
  huart1.Init.HwFlowCtl = UART_HWCONTROL_NONE;
  huart1.Init.OverSampling = UART_OVERSAMPLING_16;
  huart1.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;
  huart1.Init.ClockPrescaler = UART_PRESCALER_DIV8;
  huart1.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;
  if (HAL_UART_Init(&huart1) != HAL_OK)
  {
    Error_Handler();
  }
  if (HAL_UARTEx_SetTxFifoThreshold(&huart1, UART_TXFIFO_THRESHOLD_1_8) != HAL_OK)
  {
    Error_Handler();
  }
  if (HAL_UARTEx_SetRxFifoThreshold(&huart1, UART_RXFIFO_THRESHOLD_1_8) != HAL_OK)
  {
    Error_Handler();
  }
  if (HAL_UARTEx_EnableFifoMode(&huart1) != HAL_OK)
  {
    Error_Handler();
  }
  /* USER CODE BEGIN USART1_Init 2 */

  /* USER CODE END USART1_Init 2 */

}```

ASELSTM commented 4 years ago

Hi @rxa1031,

Thank you for this report. However, may I ask you for some questions to better understand the issue.

When sending bytes from laptop, do you also observe the same issue ? Is the last byte still missing?
Could you please mention the exchanged data, whether if only 2bytes was sent and then received or more ?
Would you please retry with FIFO mode disabled and check if the same behavior is notified, if you still don't receive the last byte.
Could you please share the whole CubeMx project you have used to reproduce the issue.

Thank you in advance for your answers.

rxa1031 commented 4 years ago

Dear @ASELSTM

STM32Cube repository starting path on my laptop is C:/STM32Cube/Repository/.....

I assume the issue is either because of the UART to RS232 converter IC (i.e. ST3241EBPR) and/or because of the signal latency (with signal latency because of track length (and external cable length if applicable) being more that code's time to check for last receive byte in case of FIFO Enabled). The issue is observed when FIFO Mode for UART is ENABLED.

Below are answers to your Queries. After answering your queries, I have shared some important observations for your review:

Q1: When sending bytes from laptop, do you also observe the same issue ? Is the last byte still missing? A1: The issue is observed irrespective of the source of the generator of the received bytes. The serial data generator could be: A. The micocontroller itself when CN2 pins 2 and 3 are shorted together so that the microcontroller transmitted serial data is received back by itself. B. External source like a Laptop. I use a BAFO serial/RS232 to USB converter. I use RealTerm to transmit bytes. The configuration is 115200 bps, 8-N-1, no flow control.

Q2. Could you please mention the exchanged data, whether if only 2 bytes was sent and then received or more ? A2. The transmitted test data is 0xA5, 0x55. Same data is expected to be captured by UART in Receive Interrupt mode. Observation shared as attachment Debug-View.png. It is observed that the last byte (which being 0x55) is never received.

Q3. Would you please retry with FIFO mode disabled and check if the same behavior is notified, if you still don't receive the last byte. A3. The serial data reception WORKS FINE when FIFO MODE is DISABLED.

Q4. Could you please share the whole CubeMx project you have used to reproduce the issue. A4. Please find attached the 7ZIP of the test code. I have renamed the _clean.bat to _clean.txt, so that I am able to send this email along with the 7ZIP file. UART-IT.zip

I have following observations when using the STM32H743I-EVAL board for testing UART Receive with Interrupt functionality.

ISSUE IS OBSERVED when below code is available inside function MX_USART1_UART_Init(void). If the Enable FIFO Mode function call is replaced by Disable FIFO Mode function call the issue is not observed.
```
  if (HAL_UARTEx_EnableFifoMode(&huart1) != HAL_OK)
  {
    Error_Handler();
  }
```
1. The ISSUE IS OBSERVED when a RS232 compatible source is connected to CN2 to send serial data bytes to microcontroller. I am using a BAFO USB to RS232 converter for Transmitting Bytes from my Laptop to microcontroller.
2. The ISSUE IS OBSERVED when pins 2 and 3 of CN2 are shorted and the microcontroller transmitted bytes are received back by the microcontroller.
3. The ISSUE IS NOT OBSERVED if wires are taken from SB46 and SB51 and Ground and connected to a FTDI chip that helps communicate with microcontroller with help of 3V3 logic level UART signal, with Laptop transmitting bytes to the microcontroller.

Please share your views.

Thanks, Rajeev

ASELSTM commented 4 years ago

Hi @rxa1031,

First of all, allow me to thank you for the provided details, it has allowed us to get an initial lead on the origin of the problem.

However, for a more in-depth analysis, may I ask you to retry once again after updating the RX_FIFO_DEPTH to 16U instead of 8U and keep FIFO enabled.

Thank you,

rxa1031 commented 4 years ago

Hi,

The issue seems to be resolved after I made the change that you informed.

In the file C:\STM32Cube\Repository\STM32Cube_FW_H7_V1.7.0\Drivers\STM32H7xx_HAL_Driver\Src\stm32h7xx_hal_uart_ex.c, I changed:

define RX_FIFO_DEPTH 8U

to:

define RX_FIFO_DEPTH 16U

The TX_FIFO_DEPTH is not changed and stays 8U.

Thanks for the help.

Regards, Rajeev

From: ASELSTM notifications@github.com Sent: Wednesday, April 15, 2020 4:00 PM To: STMicroelectronics/stm32h7xx_hal_driver stm32h7xx_hal_driver@noreply.github.com Cc: Arora, Rajeev (BLR) Rajeev.Arora2@sbdinc.com; Mention mention@noreply.github.com Subject: Re: [STMicroelectronics/stm32h7xx_hal_driver] STM32H7XX_HAL_UART.C issue: USART1 in asynchronous mode unable to receive the very last transmitted byte (#1)

// External Email, Please Be Safe //

Hi @rxa1031https://urldefense.com/v3/__https://github.com/rxa1031__;!!JCruJraw!ZwXb1MymlmdIHIufuFjy1M81e9wWVk7ny8YzLgK5S0FeJcKWdyQLL7LL3L8R2_QSbak$,

First of all, allow me to thank you for the provided details, it has allowed us to get an initial lead on the origin of the problem.

However, for a more in-depth analysis, may I ask you to retry once again after updating the RX_FIFO_DEPTHhttps://urldefense.com/v3/__https://github.com/STMicroelectronics/stm32h7xx_hal_driver/blob/b1c3ba014904de02274c7ff901f0226ad6f20238/Src/stm32h7xx_hal_uart_ex.c*L63__;Iw!!JCruJraw!ZwXb1MymlmdIHIufuFjy1M81e9wWVk7ny8YzLgK5S0FeJcKWdyQLL7LL3L8RIbc5EFU$ to 16U instead of 8U and keep FIFO enabled.

Thank you,

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/STMicroelectronics/stm32h7xx_hal_driver/issues/1*issuecomment-613957119__;Iw!!JCruJraw!ZwXb1MymlmdIHIufuFjy1M81e9wWVk7ny8YzLgK5S0FeJcKWdyQLL7LL3L8R92A0z5Q$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AEKRY4ZF3QIYDJN6BBI5HXDRMWEEJANCNFSM4LDCDHOA__;!!JCruJraw!ZwXb1MymlmdIHIufuFjy1M81e9wWVk7ny8YzLgK5S0FeJcKWdyQLL7LL3L8RMiJAQhU$.

ASELSTM commented 4 years ago

Hi Rajeev,

Glad that everything is going well now and that the problem has been solved, thank you once again for pointing out this issue.

An internal bug tracker will be opened and the correction will be available in a future release. Thank you once more for your contribution.

With regards,

GCASTM commented 4 years ago

Hi Rajeev, In order to complete the patch, and in case you have to use FIFO mode on TX, you could also update TX_FIFO_DEPTH define to 16U. Regards

ASELSTM commented 4 years ago

ST Internal Reference: 84706

rxa1031 commented 4 years ago

I earlier raised this issue on ST Portal. The case# is 00101074

Thanks for sharing the fix.

Regards, Rajeev

ASELSTM commented 4 years ago

Hi @rxa1031,

The fix you requested has been implemented and is now available in the frame of the latest stm32h7_hal_driver package V1.9.0 release. This issue can be closed now. Thank you again for your contribution.

With regards,

STMicroelectronics / stm32h7xx-hal-driver

STM32H7XX_HAL_UART.C issue: USART1 in asynchronous mode unable to receive the very last transmitted byte #1

define RX_FIFO_DEPTH 8U

define RX_FIFO_DEPTH 16U