2015-07-17 02:28 AM
We have experienced EWG error when calling HAL_CAN_Transmit_IT() repeatedly with the same CAN handle.
Making following changes in the hal_can could we solve this problemHAL_CAN_Transmit_IT(CAN_HandleTypeDef* hcan)
{ ... tmp = hcan->State; if((tmp == HAL_CAN_STATE_READY) || (tmp == HAL_CAN_STATE_BUSY_RX)) { __HAL_LOCK(hcan); /* Select one empty transmit mailbox */ if((hcan->Instance->TSR&CAN_TSR_TME0) == CAN_TSR_TME0) { transmitmailbox = 0; } else if((hcan->Instance->TSR&CAN_TSR_TME1) == CAN_TSR_TME1) { transmitmailbox = 1; } else if((hcan->Instance->TSR&CAN_TSR_TME2) == CAN_TSR_TME2) { transmitmailbox = 2; } else { transmitmailbox = CAN_TXSTATUS_NOMAILBOX; } if(transmitmailbox != CAN_TXSTATUS_NOMAILBOX){
.... } /* new code */ else { __HAL_UNLOCK(hcan); return HAL_BUSY; } /* end of new code */ .... + Did anyone experienced a similar problem ? + HAL should contemplate this case -> STMCubeF4 V1.7 should be fixed ? Thanks in advance! #stmcube-stm32f4-can2015-10-09 11:09 AM
Hello my friend.
I experienced the same problem and also wrote the same solution just before looking for anyone with the same problem.It makes all sense to me to have this __HAL_UNLOCK(hcan) if no mailbox is empty. It is like a semaphore. In the begin of the function there is a __HAL_LOCK and then a verification on the mailbox to get one that is free. If any of the 3 mailbox is free the function performs the transmission and unlock the semaphore. BUT, if no mailbox is free the semaphore has already being locked and is never unlocked anymore. So a __HAL_UNLOCK(hcan) on the HAL_BUSY part of this function makes complete sense.I believe it is a bug and should be on the next HAL can module revision.Best regards2015-11-18 04:49 AM
Thank you for your answer!
Yes we think ST will fix this bug.2015-11-19 07:52 AM
Hi rsp.rsp,
Could you send us your application? So, we can figure out thetestcase.Thank you-Shahrzad-2016-01-25 09:36 AM
Hi,
After investigation, the problem is confirmed and will be fixed in next releases. -Shahrzad-