Using STM32FCubeMX HAL Drivers for UART RX with unknown size data

[burak]

Posted on July 04, 2014 at 11:13

Hi;

I want to receive unknown size data from uart with isr. The problem is STM32CubeMX generated HAL UART libraries want to know incoming data size for buffer. Is there any solution other than writing my own isr routine for this problem ? STM32CubeMX always owerwrite ''void USART3_IRQHandler(void)'' and i cannot insert my code there. This is not good practice if i need to regenerate my config in CubeMX. And there is another problem involving FreeRTOS systick. Stm32FCubeMX generated code below not working correctly and cause hard fault.

/**
* @brief This function handles System tick timer.
*/
void SysTick_Handler(void)
{
xPortSysTickHandler();
HAL_IncTick();
}

Thus i always modify this code to get it work like this.

/**
* @brief This function handles System tick timer.
*/
void SysTick_Handler(void)
{
if (xTaskGetSchedulerState()!=taskSCHEDULER_NOT_STARTED)
{
xPortSysTickHandler();
}
HAL_IncTick();
}

Thanks. #receiver-timeout-api-stm32f0

[gvigelette]

Posted on July 08, 2014 at 21:41

Hi Bayrak,

I have been having the same problem with the UART code, you can get around it by setting the data buffer for the uart to 1 byte and re-initialize the  receive process after each character though I have run into problems when the data is transmitted to quickly.I was using a queue to store the bytes to be processed.If anyone else has a better solution or more insight on how to perform this task it would be greatly appreciated, since I am listening to a cellular chipset an have no idea what message will be sent to the processor.Thanks 

[Montassar BEN ROMDHANE_O]

Posted on July 09, 2014 at 11:22

Hi bayrak.burak,

You have already 3 points in your question. Please find below the appropriate answers:

1. When using the HAL UART receive API in interrupt process (HAL_UART_Receive_IT()). You have to set the size of the data amount to receive. Thus, to receive UART unknown size data you can set the data size to a large value, and customize the reception process by a timeout. Otherwise, you can proceed as explained

   vigelette.george 

   it's a good solution.
2. Concerning the limitation of overwriting the ''void USART3_IRQHandler(void)'' when generating code, we'll let STM32CubeMX team about it.
3. Concerning the FreeRTOS systick handler, we've notified STM32CubeMX team that is an issue. 

Thank you for you interset in our STM32Cube solution. Please continue providing valuable feedback.

With regards.

[jasonp4113]

Posted on July 28, 2014 at 03:01

It would be extremely handy if Cube generated a weak function in UART_Receive_IT() for each byte received instead of just when the''RxXferCount'' value runs out.

This way, if we want to, we can check each byte receivedJas

[andrey]

Posted on February 03, 2015 at 07:20

Hi, it is the worst variant to get callback 

HAL_UART_Receive_IT() only on half or full buffer. When I use UART I send text commands to RX UART. I want to set the end command symbol to HAL Driver and to get command from input buffer. 

HAL_UART_Receive_IT() have to have three states half buffer filled, full buffer and command recieved or the end symbol recieved.

[fsavaria]

Posted on February 02, 2016 at 22:37

Concerning point 1, some product family have a programmable RECEIVER TIMEOUT, in bit length, wich is exactly what you need for Modbus Over Serial Line or BACnet MS/TP.

I never met a communication standard where I would know in advance how many bytes I will get inside a frame yet, but the above two have a frame timeout (silence after the last octet).  When the sufficient amount of time have elapsed since the last octet (receiver timeout irq here!), you can then transfer the ''hardware buffer'' content inside a frame FIFO or frame QUEUE. The waiting server/client task can then do its magic with a full frame on each frame event. Any more manipulation is just plain PITA. I was really disappointed to see that the HAL driver did not include such a timeout. Since I'm currently working with an STM32F030CC, I did a really simple modification just to activate RECEIVER TIMEOUT when needed. Would have been easy to include that in the API. The F4s have that feature too, don't they? I can understand I have to use a TIM when working with the F1s since no receiver timeout is available. I actually did it with 1 TIM and 3 channels for 3 different uart receiver timeouts for a BACnet MS/TP router. You can imagine why when I have a more advance feature I want to use it! Regards,