Problem with HAL_UART_Receive_IT after enabling LWIP and FreeRTOS

[MFäh.1]

Hi

after enabling LWIP/FreeRTOS in the .ioc file, my HAL_UART_Receive_IT no longer works (worked fine before). I'm new to STM programming and have no idea what to do... Sorry if this is a plain stupid question.

Cheers

[Pavel A.]

What does your UART interrupt handler do? does it call FreeRTOS API?

[MFäh.1]

No, at the moment it just transmit the received data back (for testing).

 HAL_UART_Receive_IT(&huart2, rx_data, 10);

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)

{

 HAL_UART_Receive_IT(&huart2, rx_data, 10);

 HAL_UART_Transmit_IT(&huart2, rx_data, 10);

}

at the end i would like to send the received UART data as UDP packages

[Bob S]

Define "no longer works"

Your RX complete callback is starting a new receive into the same buffer that is it also starting a transmit. If you happen to receive more data while the TX is active it will overwrite/corrupt the outgoing data. But that doesn't have anything directly to do with FreeRTOS.

[MFäh.1]

No longer means, it works fine i see all the sent data in the output terminal. So indeed this works... But as soon as i activate lwip/freertos (without changing this part), it stop​s working... Don't know why

[Bob S]

One more time - define "stops working"? You still haven't done that. Do you stop receiving data? Stop sending data? Send the wrong data? Hard fault? Reboot? Dance a jig? What???????

And what have you done to debug this, other than stare at it and say "it doesn't work"? Do you ever get into the RX callback? Do any of the HAL functions return an error (do you even check the return values)? Does the RX interrupt actually get enabled? Check the actual UART registers.

[MFäh.1]

Dance a Jig ;-)... sorry for being imprecise, as i said i'm just starting with programming STMs:

It does not get into the RX callback (anymore). I don't know where I can check the HAL function returns (maybe you can help me here as well) since I "set" the HAL_UART_Transmit_IT once in the begining and it never goes into any other HAL functions, since the callback is not working. I see the RX interrupt enabled in the NVIC (?). So i would have guessed it gets enabled, but something seems to happens for sure with the interrupt, if i generate the code (after activating the LWIP)... It still works if I use the UART in polling mode. Might it help if i share some ".ioc" settings?

Thank you for your help

[Bob S]

A sense of humor - good 🙂

Every HAL function returns a status.

HAL_StatusTypeDef sts;
sts = HAL_UART_Transmit_IT( stuff here );
if ( sts == HAL_OK ) {
   // Good to go
}
else {
   // Not so good
}

Posting your main() plus whatever task/function starts the UART transmit would be helpful (after you've added code to check return values and tested it). .ioc file maybe as well.

[MFäh.1]

Status where it calls HAL_UART_Transmit_IT is HAL_BUSY and then never enters the callback fct.

i uploaded the .ioc and main.c files working and not working. The only difference is that i enable LWIP in the CubeMX

[Bob S]

Without looking at your code (yet) - where it calls HAL_UART_Transmit_IT() -- TRANSMIT ???? -- I thought transmit was (only) called from the RX callback. Did you mean HAL_UART_Receive_IT()?

Whichever - you have the HAL source. Single step into the HAL functions and see WHY it returns busy. Then figure out how that happened.

I'll wait while you do that.... (humming to myself)

Now that we have both looked at your code - I don;t see the code that checks the HAL return codes. But... you call HAL_UART_Receive_it() twice in main(). Once before you have configured the clocks and initialized the UART. Then again after both have been configured. I GUARANTEE the first call will not work and may probably even overwrite memory because the UART structure isn't initialized (well, it IS initialized to all zeros - i.e. NULL pointers).