Nucleo-H743ZI2 FDCAN: late trigger of Rx interrupts

[KT_Matt]

(Moved to appropriate forum from 'Feedback')

Hi,

I'm using Nuleo-H743Zi2 hardware. I have configured FDCAN1 with below configurations,

hfdcan1.Instance = FDCAN1;

hfdcan1.Init.FrameFormat = FDCAN_FRAME_FD_BRS;

hfdcan1.Init.Mode = FDCAN_MODE_NORMAL;

hfdcan1.Init.AutoRetransmission = ENABLE;

hfdcan1.Init.TransmitPause = DISABLE;

hfdcan1.Init.ProtocolException = ENABLE;

hfdcan1.Init.NominalPrescaler = prescaler;

hfdcan1.Init.NominalSyncJumpWidth = 1;

hfdcan1.Init.NominalTimeSeg1 = 13;

hfdcan1.Init.NominalTimeSeg2 = 2;

hfdcan1.Init.DataPrescaler = 1;

hfdcan1.Init.DataSyncJumpWidth = 1;

hfdcan1.Init.DataTimeSeg1 = 1;

hfdcan1.Init.DataTimeSeg2 = 1;

hfdcan1.Init.MessageRAMOffset = 0;

hfdcan1.Init.StdFiltersNbr = 0;

hfdcan1.Init.ExtFiltersNbr = 0;

hfdcan1.Init.RxFifo0ElmtsNbr = 8;

hfdcan1.Init.RxFifo0ElmtSize = FDCAN_DATA_BYTES_8;

hfdcan1.Init.RxFifo1ElmtsNbr = 8;

hfdcan1.Init.RxFifo1ElmtSize = FDCAN_DATA_BYTES_8;

hfdcan1.Init.RxBuffersNbr = 8;

hfdcan1.Init.RxBufferSize = FDCAN_DATA_BYTES_8;

hfdcan1.Init.TxEventsNbr = 8;

hfdcan1.Init.TxBuffersNbr = 8;

hfdcan1.Init.TxFifoQueueElmtsNbr = 8;

hfdcan1.Init.TxFifoQueueMode = FDCAN_TX_FIFO_OPERATION;

hfdcan1.Init.TxElmtSize = FDCAN_DATA_BYTES_8;

if (HAL_FDCAN_Init(&hfdcan1) != HAL_OK) {

Error_Handler();

}

/* USER CODE BEGIN FDCAN1_Init 2 */



FDCAN_FilterTypeDef sFilterConfig;

sFilterConfig.IdType = FDCAN_STANDARD_ID;

sFilterConfig.FilterIndex = 0;

sFilterConfig.FilterType = FDCAN_FILTER_MASK;

sFilterConfig.FilterConfig = FDCAN_FILTER_TO_RXFIFO0;

sFilterConfig.FilterID1 = 0x400;

sFilterConfig.FilterID2 = 0x5FF;



if (HAL_FDCAN_ConfigFilter(&hfdcan1, &sFilterConfig) != HAL_OK) {

// Filter configuration Error

Error_Handler();

}



if (HAL_FDCAN_Start(&hfdcan1) != HAL_OK) {

// Start Error

Error_Handler();

}

if (HAL_FDCAN_ActivateNotification(&hfdcan1,

FDCAN_IT_TX_COMPLETE | FDCAN_IT_RX_FIFO0_NEW_MESSAGE

| FDCAN_IT_BUS_OFF | FDCAN_IT_ERROR_PASSIVE

| FDCAN_IT_ERROR_WARNING, 0) != HAL_OK) {

// Notification Error

Error_Handler();

}

*****************************************************************************************************

*****************************************************************************************************

GPIO_InitTypeDef GPIO_InitStruct = {0};

RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0};

if(hfdcan->Instance==FDCAN1)

{

/* USER CODE BEGIN FDCAN1_MspInit 0 */



/* USER CODE END FDCAN1_MspInit 0 */



/** Initializes the peripherals clock

*/

PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_FDCAN;

PeriphClkInitStruct.PLL2.PLL2M = 8;

PeriphClkInitStruct.PLL2.PLL2N = 48;

PeriphClkInitStruct.PLL2.PLL2P = 2;

PeriphClkInitStruct.PLL2.PLL2Q = 8;

PeriphClkInitStruct.PLL2.PLL2R = 2;

PeriphClkInitStruct.PLL2.PLL2RGE = RCC_PLL2VCIRANGE_3;

PeriphClkInitStruct.PLL2.PLL2VCOSEL = RCC_PLL2VCOWIDE;

PeriphClkInitStruct.PLL2.PLL2FRACN = 0;

PeriphClkInitStruct.FdcanClockSelection = RCC_FDCANCLKSOURCE_PLL2;

if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK)

{

Error_Handler();

}



/* Peripheral clock enable */

__HAL_RCC_FDCAN_CLK_ENABLE();



__HAL_RCC_GPIOD_CLK_ENABLE();

/**FDCAN1 GPIO Configuration

PD0 ------> FDCAN1_RX

PD1 ------> FDCAN1_TX

*/

GPIO_InitStruct.Pin = GPIO_PIN_0|GPIO_PIN_1;

GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;

GPIO_InitStruct.Pull = GPIO_NOPULL;

GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;

GPIO_InitStruct.Alternate = GPIO_AF9_FDCAN1;

HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);



/* FDCAN1 interrupt Init */

HAL_NVIC_SetPriority(FDCAN1_IT0_IRQn, 1, 0);

HAL_NVIC_EnableIRQ(FDCAN1_IT0_IRQn);

/* USER CODE BEGIN FDCAN1_MspInit 1 */



/* USER CODE END FDCAN1_MspInit 1 */



}

The FDCAN Reception interrupts are triggered late >500ms sometimes more than a second. So the requests from master gets timed out.

a. Is the above configuration is correct?

b. If yes, what can be done to improve the performance?

[KT_Matt]

Hi @SofLit,

CAN is working at 100, 75MHz, but some of the other functionalities (working previously) got affected by these changes. Is there any known issues with the HAL/FDCAN peripheral for this H7 series?

[SofLit]

Sorry, I don't understand .. Is the CAN communication working fine now?

and what other functionalities are no more working? In next time, if you have issue please provide the details instead of supposing there is an issue in HAL or whatever so we limit many ping pongs in the thread.

Thank you.

[KT_Matt]

Yes, CAN transmission and reception are working but these changes affected other functionalities(previously working at 48Mhz like packet fragmentation). The HSE is 8MHz .

[SofLit]

Which packet fragmentation? is it a mechanism you implemented in your firmware?

If yes, I suggest to close this thread and open a new thread for this new question as you solved the issue of CAN communication.

Thank you.

[KT_Matt]

Our issue is not with respect to CAN is not working. It works. But sometime the receive interrupts are delayed/not triggering even after packet is received in hardware queue.

[SofLit]

In that case please provide a very simple CAN communication project (remove all the stuff not related to the CAN communication + if there is a CAN stack to be removed) that we can reproduce the behavior on the NUCLEO board .. we are pleased to assist you. Example: make an example with two Nucleo boards communicating together.

If it will not reproducible with a simple firmware I'm pretty sure there is something in your application that block the execution.

Thank you.