UART / USART HAL function to stop reception / HAL bug-track system

[Gustavo.Laureano]

Posted on February 16, 2017 at 17:26

Hi all

In the HAL F1, Is there a function to stop serial reception and reset the UART HAL driver state?

e.g. when I start a new reception in interrupt mode to receive 10 bytes, but after some time I decide to stop the reception and reset the uart HAL state back to 'stand by', discarding any data that (maybe) were received before completing 10 bytes (and hence before triggering the callback function)

Isn't this function lacking in HAL or am I missing something?

And another question / suggestion:

Is there any sub-forum where we can follow HAL bug-tracks / fixes / possible new HAL versions release dates and etc?

I already suggested/reported a couple of features/bugs regarding the HAL lib, but I feel like the process isn't transparent to the user (like me) at all, every time a new version is released there is no information about which bugs/features where corrected or added... 

Thanks

#stm32f1 #hal #uart #usart

[Gustavo.Laureano]

Posted on February 20, 2017 at 01:52

No one?

I will probably implement this function after understanding the inner working of the HAL and etc, but my workaround will not be granted for next versions of HAL, as the internal mechanisms of HAL can change without notice.

And about the bug/suggestions tracking system?

and/or any kind of release schedule for next HAL versions?

Thanks again!

[Guenael Cadier]

Posted on February 20, 2017 at 11:09

Hi

Laureano_Carneiro_Ca

‌,

Some improvements have been recently implemented by extending HAL services. Among new services, some are concerning abortion of communication sequences.

So, for your use case, I think that new services as :

/* Transfer Abort functions */

HAL_StatusTypeDef HAL_UART_Abort(UART_HandleTypeDef *huart);

HAL_StatusTypeDef HAL_UART_AbortTransmit(UART_HandleTypeDef *huart);

HAL_StatusTypeDef HAL_UART_AbortReceive(UART_HandleTypeDef *huart);

HAL_StatusTypeDef HAL_UART_Abort_IT(UART_HandleTypeDef *huart);

HAL_StatusTypeDef HAL_UART_AbortTransmit_IT(UART_HandleTypeDef *huart);

HAL_StatusTypeDef HAL_UART_AbortReceive_IT(UART_HandleTypeDef *huart);

might answer your needs.

I know those services have already been implemented on some HAL series (F0, F3, L4, L0, ...) and if not yet in F1, I would expect to have it be done in next release.

Regards

Guenael

[Gustavo.Laureano]

Posted on February 20, 2017 at 23:21

Nice to know Guenael!

And do you have any idea about the next cube F1 release date?

Thanks

[Guenael Cadier]

Posted on February 21, 2017 at 14:07

Next F1 Release should be available in coming release of STM32Cube MX. Not aware about exact availability date, maybe something around Week18 (?).

In the meantime, if you need to anticipate this delivery, here is something you could try : as far as I understand, your need is to be able to abort a RX in IT mode sequence. What I could propose you is to implement what will come in HAL next delivery in the 

    HAL_StatusTypeDef HAL_UART_AbortReceive(UART_HandleTypeDef *huart);

function.

This function will do what you requested (disable interrupt, reset Rx counters and reset Handle state to ready). Function below will manage to abort properly Rx sequences started in interrupt mode, but would need to be updated for DMA receive abortion. Please also consider that already received bytes are discarded (if you need to retrieve them, you could use huart->RxXferSize handle field for knowing nb of data to be received for completing the reception process, and then deduce nb of data already received and present in Rx buffer. Check to be done prior calling abort function).

Here is a possible temporary implementation (to be replaced by official one when available. below code is based on  implementation already existing in some STM32 series) :

/**

  * @brief  Abort ongoing Receive transfer (blocking mode).

  * @param  huart UART handle.

  * @note   This procedure could be used for aborting any ongoing transfer started in Interrupt

  *         This procedure performs following operations :

  *           - Disable PPP Interrupts

  *           - Set handle State to READY

  * @note   This procedure is executed in blocking mode : when exiting function, Abort is considered as completed.

  * @retval HAL status

*/

HAL_StatusTypeDef HAL_UART_AbortReceive(UART_HandleTypeDef *huart)

{

  /* Disable RXNE, PE and ERR (Frame error, noise error, overrun error) interrupts */

  CLEAR_BIT(huart->Instance->CR1, (USART_CR1_RXNEIE | USART_CR1_PEIE));

  CLEAR_BIT(huart->Instance->CR3, USART_CR3_EIE);

  /* Reset Rx transfer counter */

  huart->RxXferCount = 0x00U;

  /* Restore huart->State to Ready */

  huart->State = HAL_UART_STATE_READY;

  return HAL_OK;

}

Regrds

Guenael

[fabian239955]

Posted on April 27, 2017 at 19:25

I have a project that i need to port from an F4 to an F1. As the F4 HAL Libs already had the abort functionality and respective callbacks I used them for my implementation. I would like to avoid redoing these functions for the F1 myself.. is there any update on an expected availability of the new Cube version that extents the abort functions to the F1 family? 

[Gustavo.Laureano]

Posted on February 22, 2017 at 02:26

Thank you again Guenael

Thats exactly what I needed, I was looking at the F4 CUBE for this function..

ATM I am not yet implementing the part of my software which handles serial, but i know in advance that I am going to need it.

So your answer fits perfectly!

Regards

Gustavo

[Amel NASRI]

Posted on May 15, 2017 at 12:08

Hello,

Unfortunately there is no new version for STM32CubeF1 since a while (last one is 1.4.0). So even with upgrade to last MX version and its supported Cube package, you will not see an updated version of STM32CubeF1.

As already confirmed by

Cadier.Guenael

‌, the fix will be available in the version where implementation of UART driver will be aligned with the one available in other packages.

We will update you about release date as son as we have more details.

Sorry for the inconvenience this created for you.

-Amel