FDCAN with STM32H735

[alex31]

Hello,
Coming back from holidays, I had gdb stepped in the driver until I found the problem in FDCANv2, it's in the CAN shared memory management, and the problem arise when using H742, H743, H753, this explain why example, which use H750, works.

There is a 2560 (32 bits) words memory array that is shared among all the can drivers for filters, for rx fifos, rx/tx buffers, tx events, triggers.

In the current implementation, for the H742, H743, H753 families the sections are maximised, and there is no distinction if more than one interface is used. but that cannot be done, when all the sections are maximised, one overflow the 2560 words limits even for just one peripheral:

° 0x4000AC00 - 0x4000D3FF CAN Message RAM
° canp->ram_base is OK
° SRAMCAN_FLESA = 128
° SRAMCAN_RF0SA = 384
° SRAMCAN_RF1SA = 1536
° SRAMCAN_RBSA = 2688 <- from here, the sections are overflowing the 2560 limit
° SRAMCAN_TEFSA = 3840
° SRAMCAN_TBSA = 3904
° SRAMCAN_SIZE = 4608 <- MAX is 2560 WORDS

Can ram sections size are defined in stm32_registry.h
For now, for the H750, H72x, H73x families, sections are defined for the three scenarios : 1 or 2 or 3 can interfaces, and the values are chosen not to overflow, but it's not the case for the 74xx 75xx (other than 750) families.

Anyway adding a static_assert on the SRAMCAN_SIZE should trap the error at compile time (depending on the number of interfaces used).

Now that it works for me, I will submit a patch for the registry file.

Alexandre

[alex31]

And here the patch.

Also, this thread (FDCAN with STM32H735) has a green check (marked as solved), can you remove it until the patch has been commited in SVN ?

Alexandre

[Edoardo1982]

Hi Alex, thanks for the patch.
My work has been focused only on the H750 and H735 that I have available here.
For the other microcontrollers, I haven't checked the addresses and memory space.
I will commit your patch as soon as possible.

Edoardo

[alex31]

Hi Edoardo,

Thanks for the answer.

Another point that I would discuss, is the filter API. for the old MCUs with BXCAN interface, there is a low level API for the filtering capabilities of the CAN peripheral (canSTM32SetFilters function)

In HDCANv1/2, there is already the definitions for the in memory representation of the filters (CANRx[Standard/Extended]Filter) only is missing a setFilter API.
I wrote a trivial one for HDCANv2, I need to see how to do for HDCANv1, I think I have a nucleo G4 in a drawer to eventually test that. When I will have used these filter API in real project, I will come back for a proposal.

Don't know if it's worth thinking about high level filtering API since hardware capability is different between BXCAN and HDCAN, particularly, HDCAN can filter on range, BXCAN can only filter on mask, perhaps a common API can be done that offers range API, and try to emulate it with masks on BXCAN hardware ? should we discuss that on the discord channel ?

Alexandre

[alex31]

Hello,

I made some modifications on BxCAN/FdCAN drivers to :

* add :

° filtering to FdCANv1, v2 : both native and BxCAN compatible API
° filtering API that can be called after CANStart to BxCAN
° possibility to send FDCan frames to FDCANv1 (was there in V2)

* fix :
registry file (same patch as was already submited)

Here is the cumulative patch.
Alexandre

[Edoardo1982]

Hello,

I made some modifications on BxCAN/FdCAN drivers to :

* add :

° filtering to FdCANv1, v2 : both native and BxCAN compatible API
° filtering API that can be called after CANStart to BxCAN
° possibility to send FDCan frames to FDCANv1 (was there in V2)

* fix :
registry file (same patch as was already submited)

Here is the cumulative patch.
Alexandre

Hi,
sorry for the delayed response but I have been very busy with other tasks.
The absence of a setFilter function in the HAL is due to the strong dependence on the architecture.
Thank you for the patch, as soon as possible, I will integrate the parts concerning the filters into the trunk.
The previous patch has already been integrated with the necessary modifications.

Edoardo

[Giovanni]

Hi,

What is the status of this activity?

Giovanni

[nikiwaibel]

i may add my 5cent for FDCANv2 on STM32H7A3 …

• it actually supports more interrupts then RX-FIFO-FULL when receiving frames: there is RX-FIFO-WATERMARK and RX-FIFO-NEWMESSAGE (see RM0455, 2457/2966, FDCAN_IE bit 0, 1, 4 and 5). the testhal CAN code works properly, as it generates a lot of CAN frames (fifo fills rapidly). but if you need to react instantly to a single frame, you are out of luck with the current implementation, i guess. it would be nice to be able to configure the watermark via CANConfig.
• setting the FIFO size to 1 frame may be a possible solution also to react instantly (and use the already implemented RX-FIFO-FULL interrupt). unfortunately, the current implementation does not support setting the fifo size (ie via CANConfig) - see below for some example code to set the fifo size.
• i am quite unsure, if CAN_MAILBOX_TO_MASK() and canmbx_t is used properly everywhere. it seems to me, that it is used as a bitfield in some places and as number in some other places. it does not matter, so far, as there is only 1 TX FIFO and only 2 RX FIFOs. 1 = 1 and 2 = 2, no matter, if bitfield or number, as 0 is used for CAN_ANY_MAILBOX.

(the things mentioned may apply to FDCANv1 also).

setting the FIFO size to 1 frame for both RX FIFOs:

Code: Select all

CAND1.fdcan->CCCR  |= FDCAN_CCCR_INIT_Msk;
while (!(CAND1.fdcan->CCCR & FDCAN_CCCR_INIT_Msk));   /* need to wait, due to different clock domains */
CAND1.fdcan->CCCR  |= FDCAN_CCCR_CCE_Msk;   /* can only be set, if INIT is set. enables write from CPU. */
CAND1.fdcan->RXF0C &= ~FDCAN_RXF0C_F0S_Msk;
CAND1.fdcan->RXF0C |= (1 << FDCAN_RXF0C_F0S_Pos) & FDCAN_RXF0C_F0S_Msk;
CAND1.fdcan->RXF1C &= ~FDCAN_RXF1C_F1S_Msk;
CAND1.fdcan->RXF1C |= (1 << FDCAN_RXF1C_F1S_Pos) & FDCAN_RXF1C_F1S_Msk;
CAND1.fdcan->CCCR  &= ~FDCAN_CCCR_INIT_Msk;   /* also clears CCE. */


[Edoardo1982]

i may add my 5cent for FDCANv2 on STM32H7A3 …

• it actually supports more interrupts then RX-FIFO-FULL when receiving frames: there is RX-FIFO-WATERMARK and RX-FIFO-NEWMESSAGE (see RM0455, 2457/2966, FDCAN_IE bit 0, 1, 4 and 5). the testhal CAN code works properly, as it generates a lot of CAN frames (fifo fills rapidly). but if you need to react instantly to a single frame, you are out of luck with the current implementation, i guess. it would be nice to be able to configure the watermark via CANConfig.
• setting the FIFO size to 1 frame may be a possible solution also to react instantly (and use the already implemented RX-FIFO-FULL interrupt). unfortunately, the current implementation does not support setting the fifo size (ie via CANConfig) - see below for some example code to set the fifo size.
• i am quite unsure, if CAN_MAILBOX_TO_MASK() and canmbx_t is used properly everywhere. it seems to me, that it is used as a bitfield in some places and as number in some other places. it does not matter, so far, as there is only 1 TX FIFO and only 2 RX FIFOs. 1 = 1 and 2 = 2, no matter, if bitfield or number, as 0 is used for CAN_ANY_MAILBOX.

(the things mentioned may apply to FDCANv1 also).

setting the FIFO size to 1 frame for both RX FIFOs:

Code: Select all

CAND1.fdcan->CCCR  |= FDCAN_CCCR_INIT_Msk;
while (!(CAND1.fdcan->CCCR & FDCAN_CCCR_INIT_Msk));   /* need to wait, due to different clock domains */
CAND1.fdcan->CCCR  |= FDCAN_CCCR_CCE_Msk;   /* can only be set, if INIT is set. enables write from CPU. */
CAND1.fdcan->RXF0C &= ~FDCAN_RXF0C_F0S_Msk;
CAND1.fdcan->RXF0C |= (1 << FDCAN_RXF0C_F0S_Pos) & FDCAN_RXF0C_F0S_Msk;
CAND1.fdcan->RXF1C &= ~FDCAN_RXF1C_F1S_Msk;
CAND1.fdcan->RXF1C |= (1 << FDCAN_RXF1C_F1S_Pos) & FDCAN_RXF1C_F1S_Msk;
CAND1.fdcan->CCCR  &= ~FDCAN_CCCR_INIT_Msk;   /* also clears CCE. */


Your observations are correct. We could consider allowing the user to select and configure their preferred working mode.
I will check the modifications needed to add this new feature and conduct thorough tests.

Edoardo

[Edoardo1982]

Hello,

I have made the changes to the FDCANv1 and FDCANv2 drivers in the ChibiOS trunk (rev 16769).
The behavior of both drivers is now the same: an event is triggered as soon as there is a message in the RX FIFO.
It will be the application's responsibility to read all the messages that the RX FIFO can hold.
This is the best solution, as it allows us to avoid too many IRQs.

Edoardo