2017-02-16 08:26 AM
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 #usartSolved! Go to Solution.
2017-02-20 02:09 AM
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
2017-02-19 04:52 PM
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!
2017-02-20 02:09 AM
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
2017-02-20 02:21 PM
Nice to know Guenael!
And do you have any idea about the next cube F1 release date?
Thanks
2017-02-21 06:07 AM
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
2017-02-21 05:26 PM
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
Gustavo2017-04-27 12:25 PM
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?
2017-04-28 03:48 AM
Hello,
As far as I know, my understanding is that next F1 release is expected to be soon available on web. It would be V1.5.0. It will be delivered in synchronisation with next STM32Cube release (v4.21), and could occur at end of next week (W18).Regards
Guenael
2017-05-14 05:20 AM
So I just migrated to the new Firmware packages, and it seems the
Transfer Abort functions have not been added to the F1 Line. This is rather unfortunate for me, I really hoped using a HAL like cube would make migrating between Devices easier. Any information on if/when the F1 Firmware packages will get this functionality?
2017-05-15 03:08 AM
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
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.