UART Driver for STM32F413H

[Poonam Deoghare]

Posted on April 23, 2018 at 10:07

Hi All,

I am working with STM32F413H disco kit. Configured UART2 driver with 4 wires(Tx,Rx,CTS,RTS).

I am using UART in interrupt mode. Trying to send and receive some data with loopback test.

But when UART_Recv_IT is getting called, it returns HAL_BUSY and I am not able to receive data which i have sent.

I am using STM32Cube V1.0 version 4.23.0. Is there any fault in the UART driver?

This is my code:-  I am calling call back functions as well.

uint8_t rxData[128], rxBuf[128];

uint8_t txData[128];volatile uint16_t i = 0;volatile uint16_t rxDone = 0;volatile uint16_t txDone = 0;

    HAL_UART_Receive_IT(&huart2,rxData,1);

    //HAL_Delay(100);    while(rxDone == 1){}    HAL_UART_Transm    it_IT(&huart2,txData,6);    HAL_Delay(100);    while(txDone == 1){}    HAL_UART_Receive_IT(&huart2,rxData,6);        HAL_Delay(100);    printf(' rxData is %s\n',rxData);

void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart)

{    txDone = 1;}

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)

{      rxDone=1;}

[waclawek.jan]

Posted on April 23, 2018 at 22:12

The transmitting function transmits the bytes, and does not care whether something at the other end captures them. So the bytes simply 'fall into void'.

The receiving function, when run later, then has nothing to receive (it 'receives' the last transmitted byte, as it remains in UART's Rx buffer; together with an 'overflow' flag indicating, that there were other bytes but there was nothing to pick them up from the UART's Rx buffer).

The idea of transmitting and receiving bytes separately in packets is mostly flawed, and may work only in very special cases in few applications. Normally, you write the Tx and Rx interrupt routines so that they transmit/receive bytes from/to ring buffers, and then handle these buffers in your main program. I don't use Cube so don't know if this can be managed in Cube and if so, how.

JW

[Tesla DeLorean]

Posted on April 23, 2018 at 22:31

That's really a small subset of the code required to initialize the pins and peripherals. An IRQ Handler will also be needed.

Might want to start with a simple polled implementation first, and transmitting characters you can confirm on a scope.

Your CubeMX is also two revisions behind current, not sure of the value of relitigating bugs/issues that might have been addressed already.

Your description lacks any specificity to the pins being used, or how the huart2 structure is initialized.

Break the problem down into simple pieces that you can test and confirm against the hardware functionality described in the Reference Manual.