Query: Why check / call IS_FDCAN_MAX_VALUE() and IS_FDCAN_STD_FILTER_TYPE() when sFilterConfig->FilterConfig == FDCAN_FILTER_DISABLE || sFilterConfig->FilterConfig == FDCAN_FILTER_HP

[rxa1031]

Hello,

Please check below line of code: https://github.com/STMicroelectronics/STM32CubeH7/blob/5975bffae9358bc2b2890a35a203d940a395efef/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_fdcan.c#L1831

Why check / call IS_FDCAN_MAX_VALUE() and IS_FDCAN_STD_FILTER_TYPE() when sFilterConfig->FilterConfig == FDCAN_FILTER_DISABLE

There could be scenarios where a particular Filter need to be disabled if there is no longer need to receive certain CAN messages.

Regards @rxa1031

[rxa1031]

Hello,

For understanding purpose, may I assume that FDCAN_FILTER_HP means FDCAN_FILTER_TO_RXBUFFER + HIGH_PRIORITY?

May I assume Buffers are being used for FDCAN_FILTER_HP (and that FIFOs are not used)?

Please suggest.

Thanks, Rajeev

[ASELSTM]

ST Internal Reference: 121502

[rxa1031]

Accidentally clicked on Done while reviewing the issue content.

[ASELSTM]

Hi @rxa1031,

The checks are used to verify the integrity of user inputs in sFilterConfig->FilterID2 and sFilterConfig->FilterType regardless of FilterConfig value. By avoiding these checks, the construction of the filter element could be defective.

In fact, FilterID2 is uint32_t variable, supposing the following scenario:

User sets sFilterConfig->FilterID2 = 0xFFFF07FF and chooses, a deactivated filter element configuration, sFilterConfig->FilterConfig = FDCAN_FILTER_DISABLE. In this case, we will build a faulty filter configuration using FilterElementW1 (= FilterID2 = 0xFFFF07FF) and written FilterConfig will be FDCAN_FILTER_TO_RXBUFFER instead of intended FDCAN_FILTER_DISABLE value.

Hope this will help you.

[ASELSTM]

Hi @rxa1031,

Please allow me to close this thread as no activity. You may reopen it at anytime if you have any details to share with us in order to help you to solve the issue. Thank you for your comprehension.

With regards,