HAL_UART_TxCpltCallback Issue at Higher Buadrate

[JThom.15]

Hi all,

I am using UART4 in STM32F205 connected to an external device with an RS485-Transceiver (sn65hvd75).When I transmit data (HAL_UART_Transmit_IT) I set the TXEN pin high in RS485-Transceiver and when I get a callback  using HAL_UART_TxCpltCallback, I reset the TXEN pin to receive the data, It works fine in lower baudrates(9600), but at higher baudrate(115200) the response from external device gets corrupted because the TXEN has not been resetted before we start receiving data.

Does anyone know whether there is delay in HAL_UART_TxCpltCallback or is there any other way to make sure the transmit is complete (to reset the TXEN pin)?

[Sarra.S]

Hello @JThom.15, 

If you're not already using DMA for UART transmission, consider using it, it can help with reducing the delay with less CPU intervention. 

 

[TDK]

HAL_UART_TxCpltCallback is not called instantly, but it will be called fairly quickly. What timing requirement do you have here?

I'd suggest calling HAL_UART_Receive_IT prior to the transmission being complete so that you're ready to receive data when it happens. It doesn't seem like the TXEN signal should be affecting received bytes.

[JThom.15]

@TDK Thanks for the reply

I use the HAL_UART_TxCpltCallback to set the TXEN low. 

I used the scope and it seems like TXEN held high little bit longer even after the transmit is finished and recieve msgs are not getting through.

 

[TDK]

> I used the scope and it seems like TXEN held high little bit longer even after the transmit is finished and recieve msgs are not getting through.

Do you think the two are connected? And if so why?

We don't know what "recieve msgs are not getting through" means in particular. Perhaps explain the symptoms in more detail. What debugging have you done? Does anything get through, if so what? What does your reception code look like?

[mbrossett]

What clock frequency are you running? Below is a link to an ST app note on managing the driver enable pin for RS-485 applications. They provide timing measurements for an STM32F10x and it meets the requirements for 230,400 baud at 72MHz and 24MHz clock frequencies. You should have no problem at 115,200 baud. 

https://www.st.com/resource/en/application_note/an3070-managing-the-driver-enable-signal-for-rs485-and-iolink-communications-with-the-stm32s-usart-stmicroelectronics.pdf