Is it possible to use both FDCANs in an STM32H753 MCU at the same time?

[MNagl.1]

The errata sheet of these MCUs says:

2.16.2 Wrong data may be read from Message RAM by the CPU when using two FDCANs

Description

When using two FDCAN controllers, and the CPU and FDCANs simultaneously request read accesses from Message RAM, the CPU read request may return erroneous data.

The issue is not present if the CPU requests write access to Message RAM.

Workaround

To avoid concurrent read accesses between the CPU and FDCANs, use only one FDCAN at a time.

Does this mean it is not possible to use both FDCAN interfaces at the same time (i.e. one has to be stopped before the other may be started) or is there a less limiting workaround? I would like to connect to two different busses using the two FDCAN blocks. If it is not possible to use both at the same time, this usage would not be possible with this MCU...

[Imen.D]

Hello @MNagl.1​ ,

It’s not recommended to use two FDCANs at the same time because we can have corrupted data. This means that we cannot use them in communication at the same time. They can be used alternately.

We recommend to design with revision V, which fixes this issue.

Best Regards,

Imen

[MNagl.1]

Dear Imen,

thanks for this information! Fortunately we are using rev. V. In the meantime I found the real reason for the issues I was experiencing: The CubeIDE does not calculate a proper Message RAM offset for CAN2 and sets both offsets to 0 by default. Then of course both CAN blocks write to overlapping RAM areas. As an improvement, it would be great if the CubeIDE calculated the RAM offset for CAN2 automatically since it has got all necessary information to determine the RAM size needed by CAN1 and thus the minimum offset value for CAN2.

Greetings,

Matthias

[MGerh.1]

Hello,

with our current project we have to use both CAN interfaces and I'm actually unsure about how to understand the errata sheet and information in this thread.

The actual errata sheets for the STM32H743 and STM32H753 list devices with the device marking V and accordingly REV_ID 0x2003 as affected variants.

My questions:

1. Is "rev. V" related to the the device marking?
2. In the case "rev. V" means the device marking: Why is the issue still for rev. V in the related errata sheets? Last update of the errata sheets was on 12-Feb-2021.

Best Regards,

Michael

[MBC]

Same question, as MGerh.

Does the V revision of the STM32H743 have the two CAN at the same time issue?

[Imen.D · Accepted solution]

Hi @MBC​ ,

According to the table 3 in the STM32H743xI/G Errata sheet (ES0392 Rev 😎 : this FD-CAN limitation is absent from the revision V.

 

Hope that I've answered your question.

Thanks

Imen