FDCAN H5 Memory Access Failure

[dnugent]

I'm experiencing FDCAN Memory Access Failures on the STM32H503KBUX during CAN Rx. 

I am also experiencing intermittent CAN Rx message drops (every 1 in a 200), and I believe the two are related since no others errors are firing. I know the drops are happening on the STM32 because I can see the messages on the bus with my CAN debugger and there are no error frames. 

I'm struggling to understand why this Memory access error is happening and how to proceed with solving it. The only info I can find is in rm0492. However, it doesnt really say what might cause these events to happen. 

Other relevant info:

- Using internal clock
- Freertos

- Using to `HAL_FDCAN_RxFifo0Callback` to read from FIFO

- Config

  hfdcan1.Instance = FDCAN1;
  hfdcan1.Init.ClockDivider = FDCAN_CLOCK_DIV1;
  hfdcan1.Init.FrameFormat = FDCAN_FRAME_CLASSIC;
  hfdcan1.Init.Mode = FDCAN_MODE_NORMAL;
  hfdcan1.Init.AutoRetransmission = ENABLE;
  hfdcan1.Init.TransmitPause = ENABLE;
  hfdcan1.Init.ProtocolException = ENABLE;
  hfdcan1.Init.NominalPrescaler = 16;
  hfdcan1.Init.NominalSyncJumpWidth = 128;
  hfdcan1.Init.NominalTimeSeg1 = 13;
  hfdcan1.Init.NominalTimeSeg2 = 2;
  hfdcan1.Init.DataPrescaler = 1;
  hfdcan1.Init.DataSyncJumpWidth = 16;
  hfdcan1.Init.DataTimeSeg1 = 1;
  hfdcan1.Init.DataTimeSeg2 = 1;
  hfdcan1.Init.StdFiltersNbr = 1;
  hfdcan1.Init.ExtFiltersNbr = 1;
  hfdcan1.Init.TxFifoQueueMode = FDCAN_TX_FIFO_OPERATION;

- Using a filter

void can_setupFilter(void) {
	FDCAN_FilterTypeDef sFilterConfig;
	sFilterConfig.IdType = FDCAN_EXTENDED_ID;
	sFilterConfig.FilterIndex = 0;
	sFilterConfig.FilterType = FDCAN_FILTER_RANGE;
	sFilterConfig.FilterConfig = FDCAN_FILTER_TO_RXFIFO0;
	sFilterConfig.FilterID1 = 0;
	sFilterConfig.FilterID2 = 0x1FFFFFFF;

	if (HAL_FDCAN_ConfigFilter(canPtr, &sFilterConfig) != HAL_OK) {
		Error_Handler();
	}
}

Happy to share additional details upon request.

Any ideas on how to debug or fix this issue?

Best,

Daniel

[mƎALLEm]

Hello,

---

@dnugent wrote:

- Using internal clock

---

1- Not recommended. Please use a crystal or other precise source of clock.

---

@dnugent wrote:

- Freertos

---

2- Better to do the test without RTOS.

3- Try to increase the value of the extended filter number:

 hfdcan1.Init.ExtFiltersNbr

[dnugent]

Thank you for your response!

Increasing filter number did not help.

I was able to subdue the MRAF error by creating a new barebone project, however, I still have packet drops. 

The new bare bones project just has FDCAN enabled and no FreeRTOS. Im sending a fixed number of messages from a working STM32 and counting them with my CAN debugger and the H5. This new project still has a drop rate of 1 in 200.

I've ordered a dev board to see if the external oscillator helps. I will report back with my findings.

Thanks,

Daniel

[dnugent]

I misspoke, the MRAF error is still firing with the barebones project. 

[dnugent]

My leading suspect is the lack of HSE. Could you explain to me why that would cause MRAF errors and not some other type of error?

Additionally, after further reflection on the MRAF description:

has not completed acceptance filtering or storage of an accepted message until the
arbitration field of the following message has been received. In this case acceptance
filtering or message storage is aborted and the Rx handler starts processing of the
following message.

Is it possible my FDCAN Kernel clock is too slow and thats why it cant complete the acceptance filtering in time? It was was 64MHz but I upped it to 100Mhz. However, its still throwing MRAF errors. Does it need to be even faster?

Additionally, you mentioned increasing the number of extended filters. Why is that? I only configure a single filter so only a single filter slot should be needed. Am I missing something?

Thanks,

Daniel

[dnugent · Accepted solution]

I found the issue. It was a slow clock speed issue. 

The FDCAN peripheral has 2 clocks: the FDCAN kernel clock controls the bit timing and APB1 controls the RX handler (and other stuff). It was the APB1 clock being too slow and not running the acceptance filter fast enough. It was clocked at 32Mhz so I upped it to 128Mhz and that fixed the issue.

I did end up keeping FDCAN kernel clock at 100Mhz because we have other projects running at this speed so I kept it high.