STM32U575CGU3 CAN Cycle Time Issue

[sasmitjoshi5]

I am using the STM32U575CGU3 MCU in my project, where I transmit data using two CAN frames on the bus. I have configured a CAN transmission cycle time of 250 ms in my software.

However, on a few PCB assemblies, I am observing inconsistencies in the transmission cycle time. On few boards, the cycle time appears to fluctuate (e.g., around 0.5–0.6 ms deviation), while on other boards, it works well.

Could you please help me understand what might be causing this variation across different PCBAs? Any guidance on potential root causes or debugging approaches would be highly appreciated.

[mƎALLEm]

Hello,

How are you managing that "cycle time"? using HAL_Delay in a loop? or over a timer interrupt? using a crystal instead of one of the internal RC clock sources?

But 0.5 to 0.6ms deviation vs 250ms between frames seems to be acceptable 0.24% of deviation! 

[sasmitjoshi5]

Hello, 
I am managing cycle time using timer interrupt. I am using external crystal - MC2016Z16.0000C19XSH. 
Sorry my bad, 0.5-0.6 ms is not a deviation, I have set 250 ms cycle time & for few PCBAs it goes for 0.5 or 0.6 ms cycle time, instead of 250 ms. 

[mƎALLEm]

Hello,

In that case this is a timer question not CAN question. The timer usage changes totally the context as you don't have CAN communication problem.

Forget about CAN for now. Comment out the CAN transmission from the timer interrupt and toggle a pin instead. Do you have the same behavior?

[sasmitjoshi5]

Hello, 
Earlier I had 16 MHz as a sysclk & 128 MHz as a FDCAN clock. I have change sysclk to 128 MHz & my problem got resolved as of now. Both sysclk & CAN clock are same 128 MHz now. I have a question, is it safe to use sysclk at 128 MHz?

[mƎALLEm]

Hello,

You can reach up to 160MHz with the system clock. 

I think you have errors with the CAN communication at 16MHz clock for FDCAN I don't know what is the problem root cause.

[Ozone]

> I am using the STM32U575CGU3 MCU in my project, where I transmit data using two CAN frames on the bus. I have configured a CAN transmission cycle time of 250 ms in my software.

The CAN bus is not deterministic, since messages are arbitrated by message IDs.
This means, a node will be blocked while others transmit, when it "loses out" the arbitration.

Validate the timing of your MCU and firmware by other means, and check that the CAN bus timing fluctuations remain in acceptable bounds. For that, you need a reference system with a minimum of nodes, preferably only two.

BTW, there is no such thing as a "configured CAN transmission cycle time" in standard CAN.
Some higher-level protocols like CANopen organize the bus in "cycles", and thus have "cycle times".
This is not a feature of the CAN specification and the CAN peripheral, though.