bxCAN HAL HAL_CAN_RxFifo0MsgPendingCallback behavior - callback being called repeatedly
Using STM32L452 and HAL version 1.17.2 with FreeRTOS. I'm new to CAN, and am trying to set up a simple one-to-one communication scheme without filters (only two devices on this CANbus talking to each other). I've implemented the RX FIFO message pending callback such that it simply sends a FreeRTOS notifier:
void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan)
{
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
if (xTaskGetSchedulerState() != taskSCHEDULER_NOT_STARTED) // Be sure CAN RX task is running before we try to wake it
{
HAL_CAN_DeactivateNotification(&hcan1, CAN_IT_RX_FIFO0_MSG_PENDING); //BDRTEMP Disable this interrupt until the RX task services
vTaskNotifyGiveFromISR(CANRxTaskHandle, &xHigherPriorityTaskWoken); // Wake the CAN RX task
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}
}
The notifier wakes up a FreeRTOS task that reads the CANbus message and processes it:
void StartCANRxTask(void const * argument)
{
/* USER CODE BEGIN StartCanRxTask */
BaseType_t status;
/* Infinite loop */
for(;;)
{
// Wait for data ready semaphore
ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
// CAN data received, process it
if (HAL_CAN_GetRxMessage(&hcan1, CAN_RX_FIFO0, &RxHeader, RxData) == HAL_OK)
{
CANProcessRxData(&RxHeader, &RxData[0]);
}
HAL_CAN_ActivateNotification(&hcan1, CAN_IT_RX_FIFO0_MSG_PENDING); //BDRTEMP Re-enable interrupt
/* USER CODE END StartCANRxTask */
}
What I'm puzzled about is this: If I don't use HAL_CAN_DeactivateNotification() in the RX callback as above (line with "//BDRTEMP"), the RX callback is called continually and the CAN RX task never gets a chance to read and process the received CAN message. I have to use HAL_CAN_DeactivateNotification() and HAL_CAN_ActivateNotification() as above to allow this scheme to function. Is this normal behavior for the CAN peripheral and HAL? Is there a more elegant way to keep the RX callback from just retriggering continually and allow the task to wake up and read the message? Incidentally, UM1884 seems to suggest in section 9.2.1 ("Interrupt mode operation", item 3) that this is the way it has to be done, it just seems really inelegant.