AnsweredAssumed Answered

[F2 FW1.6.0] CAN_Receive_IT why new pRx1Msg?

Question asked by Valentin on Jun 6, 2017
Latest reply on Jul 13, 2017 by Valentin



I just upgraded from F2 HAL library v1.4.0 to v1.6.0 and noticed that CAN_Receive_IT now uses two separate RxMessage buffers in its CAN_HandleTypeDef struct. One per CAN FIFO, as can be seen here:


static HAL_StatusTypeDef CAN_Receive_IT(CAN_HandleTypeDef* hcan, uint8_t FIFONumber)
  uint32_t tmp1 = 0U;
  CanRxMsgTypeDef* pRxMsg = NULL;

  /* Set RxMsg pointer */
  if(FIFONumber == CAN_FIFO0)
    pRxMsg = hcan->pRxMsg;
  else /* FIFONumber == CAN_FIFO1 */
    pRxMsg = hcan->pRx1Msg;


and here:

typedef struct
  CAN_TypeDef                 *Instance;  /*!< Register base address                                */

  CAN_InitTypeDef             Init;       /*!< CAN required parameters                              */

  CanTxMsgTypeDef*            pTxMsg;     /*!< Pointer to transmit structure                        */

  CanRxMsgTypeDef*            pRxMsg;     /*!< Pointer to reception structure for RX FIFO0 msg      */

  CanRxMsgTypeDef*            pRx1Msg;    /*!< Pointer to reception structure for RX FIFO1 msg      */

  __IO HAL_CAN_StateTypeDef   State;      /*!< CAN communication state                              */

  HAL_LockTypeDef             Lock;       /*!< CAN locking object                                   */

  __IO uint32_t               ErrorCode;  /*!< CAN Error code                
                                               This parameter can be a value of @ref CAN_Error_Code */



I wonder why that was introduced? It worked perfectly fine for me before with only one RxMessage, because during an interrupt the RxMessage memory will either be filled with a message from Fifo0 OR Fifo1 and then the Callback is executed right away which then in turn processes the just received RxMessage.

This means in no case is it ever possible to fill up pRxMsg AND pRx1Msg at the same time without processing one of them first via the callback.


I mean I don't care about the additional RAM usage on the stack but I now don't have any way to know which FIFO the message causing the current callback was coming in from.


Before I had this solution working fine for me (using only one pRxMsg = &RxMessage buffer):

static HAL_StatusTypeDef CAN_Receive_IT(CAN_HandleTypeDef* hcan, uint8_t FIFONumber)
      * Fix: get FIFO number ......

     hcan->pRxMsg->FIFONumber = FIFONumber;

  /* Get the Id */


This means I could look at pRxMsg->FifoNumber and determine from that which Fifo to restart after processing the callback function like this:

void HAL_CAN_RxCpltCallback(CAN_HandleTypeDef* hcan) {
     HAL_CAN_Receive_IT(hcan, hcan->pRxMsg->FIFONumber);


How would you suggest to do this now? Are there any examples regarding dual FIFO use out there for the new HAL version? Also I now need to figure out which of the two RxMessages actually contain the new data...