STM32H7 FDCAN clock issue

[Mr_M_from_G]

Hello all,

I have trouble running FDCAN on an STM32H742VG rev V when the cpu clock is above 300 MHz.

I have

D1CPRE = DIV1

HPRE = DIV2

D2PPRE1= DIV2

leading to the maximum allowed APB1 peripheral clock (= fdcan_pclk) for cpu clock >= 300 MHz (75 MHz for cpu clk = 300 MHz)

also I have HSE = 24 MHz used as FDCAN clk (= fdcan_ker_ck) and with FDCAN_CCU_CCFG.BCC = 1 and FDCAN_CCU_CCFG.CDIV=0 this is also fdcan_tq_clk and so fdcan_tq_clk is always smaller than fdcan_pclk.

But still this configuration only runs stable up to 300 MHz, at 330 MHz it fails after about a minute and with 360 MHz and above it does not work at all.

I have no trouble running UARTs, SPI, timers, ADC, DAC with cpu clk = 480 MHz, its only the FDCAN.

Did I miss something? Any known issues or workarounds?

Thanks for any hint

Martin

[Mr_M_from_G]

Today I built a small application using STCubeMx and the HAL functions to reproduce the problem with ST code only.

And the result is the same. Now it seems to work better with a cpu clk of 360 MHz but is unstable with 420 MHz and does not work with 480MHz.

I found that with the limit where instabilities begin the bit times change from precise multiples of 1 µsec (I am running 1 Mbit/s) to shorter recessive bit times. At a cpu clk of 480 MHz I see recessive bits of 100 nsec. I only have a lab setup with two CAN nodes and max 20 cm wires between them. The second CAN node is a CAN bus monitor that is not changed. Also I tried external loop back mode with the same result.

So currently I am convinced that this is a hardware bug. ST members can you help please.

Martin

[Karl Yamashita]

Can you upload the ioc file? I have a STM32H723 and STM32H750 that I can try to match the clock configurations to test.

[Mr_M_from_G]

Hello Karl,

here I send you the ioc file.

Different to what I wrote above I have set FDCAN to run from PLL2Q (it was HSE before. But results are the same.) so it is independent from PLL1 which I use to change cpu clk by changing DIVN1. The same is true for UART3 which is clocked by PLL3Q. I do some UART output and also send something over CAN every 500 msec in the endless loop in main.

Maybe I need to mention (not sure if that is important) that my H742 is powered with 1.8V

.

I'll be glad to read about your results

Thanks

Martin

[Karl Yamashita]

When you say unstable, what do you mean by that? Not transmitting or receiving? Both?

[Mr_M_from_G]

It means both, although most of the time I checked transmission.

This is what I did:

My setup is a short CAN bus (about 20cm with temination resistors on both ends) with the STM as one node and a CAN bus monitor (PEAK systems PCAN) as the second. On PCANs GUI I can see messages on the bus and also errors.Also I can trigger sending a message from PCAN and see if that caused errors or was acknowledged. My STM programm sends a message every 500 msec.

Now I started with a lower cpu clk and I see the messages arriving in PCAN and no errors.

When the cpu clk goes above a certain limit errors come up but still some messages are received correctly. As I wrote I found that the length of recessive bits change and I think if it is not too much sync jump width can correct that (sometimes) and still receive the message..

As the cpu clk gets even higher this compensation is not successful any more and I get only errors.

Did you check it? What are your results?

[Sven H.]

Hello,

I wanted to add a few additional comments regarding the unstable CAN bus transmissions.

I was able to reproduce it with the supplied firmware. After playing around with the firmware a bit, the problem seems to be a timing issue with the CANFD1 peripheral.

When ispecting the TXD pin of the STM32H742 on an oscilloscope the "correct" data is visible (i.e. rough spacing and relative pulse lengths match the correct transmissions). But while the falling edges seem to be stable and correctly timed, the rising edges are verry jittery and mostly too late with respect the the actual data rate. This leads to incorrect bit times and thus unreliable or impossible CAN communication.

This effect only starts to be visible on high system clock rates, the specific threshold seems to be IC specific. For lower system clocks the peripheral functions normaly, even when using the same peripheral clocks as before. I tried different ratios of system and peripheral clocks, but the result was always the same. For high system clocks, regardless of the actual peripheral clock, the CANFD1 outputs becomes unstable.

Interestingly the problem does not occur on CANFD2. I configured both peripherals using the exact same configuration and clock settings, starting the transmissions (ie. setting TXBAR after copying message to RAM) as close together as possible. While the output of CANFD1 still is undecodable, the output of CANFD2 during the exact same time is perfect.

A last effect I observed was, that halting the system via a breakpoint just after transmitting the buffer to the CANFD1 peripheral also results in a correct transmission. This, combined with the fact, that CANFD2 works using the exact same configuration, leads me to believe that the exists a timing issue or race condition in the CANFD1 peripheral, resulting in data beeing availiable too late to be clocked out resulting in unstable rising edges.

Let me know if you have additional questions regarding my observations.

Best Regards,

Sven

[LCE]

That is some valuable info, I have to get CANFD running soon on a H7 (H723..H735 series).

So I should not start with CANFD1.

Can anybody else confirm these observations?

Is that only on the H74x series?

Or depending on chip package?

[Mr_M_from_G]

The complete situation regarding the H7 family or the CANFD peripheral is unclear. Currently we could only see it on H742/3 in 100pin LQFP package.The only different thing we tested was a H743 in a NUCLEO board, but this one was > 2 years old so likely another manufacturing lot in case this plays a role.