HAL_CAN_Init() returns HAL_TIMEOUT on STM32F042

[voyvoda .]

Hello,

I generated a fresh CubeMX project which has can bus. HAL_CAN_Init() returns HAL_TIMEOUT.

What could be the possible solution ?

/* CAN init function */

static void MX_CAN_Init(void)

{

 CAN_FilterConfTypeDef sFilterConfig;

 static CanTxMsgTypeDef    TxMessage;

 static CanRxMsgTypeDef    RxMessage;

 /*##-1- Configure the CAN peripheral #######################################*/

 hcan.Instance = CAN;

 hcan.pTxMsg = &TxMessage;

 hcan.pRxMsg = &RxMessage;

 hcan.Init.TTCM = DISABLE;

 hcan.Init.ABOM = DISABLE;

 hcan.Init.AWUM = DISABLE;

 hcan.Init.NART = DISABLE;

 hcan.Init.RFLM = DISABLE;

 hcan.Init.TXFP = DISABLE;

 hcan.Init.Mode = CAN_MODE_NORMAL;

 hcan.Init.SJW = CAN_SJW_1TQ;

 hcan.Init.BS1 = CAN_BS1_4TQ;

 hcan.Init.BS2 = CAN_BS2_3TQ;

 hcan.Init.Prescaler = 48;

 if (HAL_CAN_Init(&hcan) != HAL_OK)

 {

  /* Initialization Error */

  Error_Handler();

 }

 /*##-2- Configure the CAN Filter ###########################################*/

 sFilterConfig.FilterNumber = 0;

 sFilterConfig.FilterMode = CAN_FILTERMODE_IDMASK;

 sFilterConfig.FilterScale = CAN_FILTERSCALE_32BIT;

 sFilterConfig.FilterIdHigh = 0x0000;

 sFilterConfig.FilterIdLow = 0x0000;

 sFilterConfig.FilterMaskIdHigh = 0x0000;

 sFilterConfig.FilterMaskIdLow = 0x0000;

 sFilterConfig.FilterFIFOAssignment = 0;

 sFilterConfig.FilterActivation = ENABLE;

 sFilterConfig.BankNumber = 14;

 if (HAL_CAN_ConfigFilter(&hcan, &sFilterConfig) != HAL_OK)

 {

  /* Filter configuration Error */

  Error_Handler();

 }

 /*##-3- Configure Transmission process #####################################*/

 hcan.pTxMsg->StdId = 0x321;

 hcan.pTxMsg->ExtId = 0x01;

 hcan.pTxMsg->RTR = CAN_RTR_DATA;

 hcan.pTxMsg->IDE = CAN_ID_STD;

 hcan.pTxMsg->DLC = 2;

}

[voyvoda .]

Yes I do have a transceiver.

There is no slave device on the bus.

I do not use canbus interrupt.

What ever the data was on the transmit buffer, I always get the same output which you can at the attachment.

[Tesla DeLorean]

Well if you keep cramming in packets on a bus that's not going to acknowledge anything, at some point the output buffer will fill.

Try having two devices, and build some of the examples provided in the library. Consider getting some boards with known functionality, and supporting code.

Consider using a USART to output diagnostic information, and checking the error/status returned by API functions before ploughing forward.

Pasting selective code fragments into a longer narrative is less helpful than attaching a whole .C file illustrating the full/complete scope of what you are doing.