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 @mƎALLEm,

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?

[mƎALLEm]

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 .

[mƎALLEm]

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.

[mƎALLEm]

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.

[Tesla DeLorean]

As a point of note for others landing here, the NUCLEO-H743ZI2 has an ST-LINK/V3 which isn't clocking at 8 MHz like the older ST-LINK/V2-1 designs

25 MHz internally via crystal as I recall, and there are multiple clock output options, which are generally not 8 MHz precisely, ie either HSI derived, or HSE/PLL Div 3

The settings on the ST-LINK/V3 and the STM32H7 side need to be consistent in their expectations. Think HSE_VALUE / HSE BYPASS. And CAN wants a precise/accurate clock.

https://community.st.com/t5/stm32-mcus/how-to-use-stlink-v3-mco-output-on-nucleo-boards-as-a-precise/ta-p/723361