cancel
Showing results for 
Search instead for 
Did you mean: 

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

TDJ
Senior III

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

TDJ_0-1701594422734.png

TDJ_0-1701593879620.png

The actual STM32U5 FDCAN fixed 848 byte RAM structure documented in RM0456
TDJ_1-1701593957016.png

 

4 REPLIES 4
Sarra.S
ST Employee

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. 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

TDJ
Senior III

@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
ST Employee

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. 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

TDJ
Senior III

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