FDCAN on STM32U5 and STM32H5 - serious FIFO/queue and ID filter list size limitations

[TDJ]

I am wondering if anyone notice that FDCAN on STM32U5 and STM32H5 MPUs has FIFO/queue size limited to 3 (three!) elements only.
AN5348 - FDCAN peripherals for STM32 product classes does not mentioned that anywhere. The max FIFO/queue size discussed in AN5348 is very reasonable 64 elements. Consequently, all the FDCAN memory flexibility and RAM management discussed in AN5348 section 4.2 practically does NOT apply to U5, H5, G0, G4 and L5 families. Perhaps it applies to H7 family only. See FDCAN_RXF0S[F0FL] register description in the corresponding RMxxxx document. In particular, on STM32U5 FDCAN RAM config is fixed - (RM0456, Figure 879. Message RAM configuration). E.g. if you need just one RxFIFO buffer (FIFO0), you probably cannot use RAM reserved for FIFO1. and make it bigger. That is very unfortunate. One may think: OK, so I just configure selective hardware filters to catch only those messages I need, but one can configure just 8 'extended' 29-bit filters and memory reserved for 28 11-bit filters will remain unused. That is a pity, but that is not all. Rx buffers discussed in AN5348 section 4.3.2.2-4.3.2.3 just do not exist. The same is true Tx buffers, they do not exist. RM0456 in Figure 879 mentions them, but they mean Tx FIFO/queue only, not dedicated Tx buffers.

I do not want to call this 'false advertisement', but it came as a big surprise - especially for STM32U5 with plenty of SRAM. FIFO/Queue size limited to 3 elements perhaps would be bearable if I could use extended ID filter list (min 20 elements required) to receive only interesting NMEA2000 messages and avoid software filtering. However, I need to use classic filters (ID+mask) and only 8 extended ID classic filters can be defined. Dual or range filter is not an option. Functionality is there, it was just purposely and seriously limited in this supposedly top product for no apparent reason. It is just poor-man implementation and big STM32U5 disappointment.
Am I missing something? - see below

Fully configurable 10k FDCAN RAM documented in AN5348

The actual STM32U5 FDCAN fixed 848 byte RAM structure documented in RM0456

[Sarra.S]

Hello @TDJ 

This application note is quite generic 

At the beginning of section 4, there is this note: "To fully understand the implementation and the capabilities of the FDCAN feature, refer to the product reference manual. The rest of this document will delve deeper into the advanced functionality of the FDCAN, referred to as the FDCAN superset."

I can understand your frustration, for stm32U5, STM32H5, and all the other products, the correct FIFO queue is in the reference manual and the application note does not intend to cover all this specific information. 

[TDJ]

@Sarra.S My point is that  AN5348 applies to FDCAN found in new ST MCUs only to a very limited extent and despite the disclaimer you mentioned is just highly misleading.
I understand that serious FDCAN limitations introduced in new MCUs is a conscious business decision, perhaps aimed at preventing using new MCUs in automotive applications, but in my view it went way too far and is just very disappointing.

[Sarra.S]

Hello again @TDJ, I appreciate your interpretation 

I only want to emphasize that the STM32H5 MCUs are not intended to be the STM32H7 family's successors.

It's more of a successor to the STM32F4 series that did not have the FDCAN feature. 

[TDJ]

@Sarra.S Thank you, I appreciate your official explanation, but the disappointment remains.

[waclawek.jan]

Hi @Sarra.S ,

AN5348 has been updated recently (06-Mar-2024 rev.3), yet these concerns haven't been addressed. @TDJ brought up valid points, there is a dramatic difference between usage of modules with generous amount of resources and those which are restricted. Yes, there are disclaimers and "up-to-N" formulations, but why not making the appnotes better?

I suggest to add an overview of FDCAN perpheral's configurations across the relevant ST families, in the same style as the RTC and TIM appnotes do.

@KB-IDEA 

JW

[Sarra.S]

Hello @waclawek.jan and @TDJ 

I tried pushing the requested updates internally ( ticket 179261) 

Unfortunately, there is no action planned to update this AN for the moment. 

[Kraal]

Ah, so I'm not the only one that got disappointed by the new FDCAN peripheral.

I, too, understand that some hardware choices must be made when designing such peripherals, but we have a rolling project that uses an F042 with standard CAN, and there the filters flexibility was much better.

As @TDJ said, the very limited amount of extended filter is hard to understand in the new FDCAN peripheral, especially when you get 28 standard filters (that in my case are not used and waste registers).

We moved this existing project to a G0B1, and I had to complicate a bit the CAN messaging Rx and Tx routines due to these limitations.

I may sound naive, but for future chips family, would it be possible to use this forum to post polls regarding specific features and needs. It won't be possible to please everyone with one design of course, but ST might see some clear directions or needs from the forum users.

Best regards,

Kraal

[waclawek.jan]

We used to have a yearly wishlist thread. That was mostly ignored by ST but at least we had a nice place to tell our wishes; and it was a nice tradition at the same time.

Then @Amel NASRI was forbidden to start the wishlist threads, and we were given the Ideas, which was another place ignored by ST.

Then the migratiion to Khoros happened, and ST does not feel a need anymore to have a place for users to post requests to be ignored.

@Lina DABASINSKAITE 

JW

[Lina DABASINSKAITE]

Hi @waclawek.jan , 

Thanks for sharing this. Both previous set up of Wishlist and Ideas section had some limitations and could not bring value to both ends. 

This year we will revisit this question and rethink the format to best engage on new features and proposals. I will share more news on this one later this year. 

Thanks,
Lina