How to get an 8MHz sine wave HSE output on pin MCO1 (PA8) and should it be in phase with the original crystal signal?

[jim239955_st]

I have been told i need to sync 2 STM32 MCU's together (on the same PCB) to stop an intermittent I2C bus failure between them. At the moment they are operating on separate 8Mhz crystals. I have used the following command to configure and output the 8MHz clock on MCO1 (PA8) but it is a square wave and 180 degrees out of phase.

HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSE, RCC_MCODIV_1);

I am compiling in Atollic.

What have i not done to get an in phase sine wave?

Any help would be appreciated.

[Tesla DeLorean]

Why do you need a sinewave? The filter will phase delay the signal further.

Use the HSE input in BYPASS mode.

Use one XO source and clock both with it.​

[jim239955_st]

Thank you for your reply. Ok so i was told that to have reliable comms on the I2C line between the MCU's i needed both clocks to be in sync. I have set up the second MCU to use the HSE input in bypass but if the square wave output of MCO1 is 180 degrees out of phase with the original crystal oscillator output then surely when it is input to the second MCU it will make them clock at 180degrees phase difference? or does that not matter?

[Tesla DeLorean]

Which STM32 are involved? Are you using the PLL to get to a higher frequency?

Can't you clock from the same source if this really is an issue you want to test?

I'm guessing the I2C is clocking an order of magnitude slower.

Do they really need to be in phase synchronization? From the same synchronous source the clocks won't drift or beat with respect to each other.

Are you sure this is the real cause of your problems? Seems like a grasping at straws approach to some other problem you haven't well defined or confined.

Is the I2C Slave device less responsive than the master expects it to be. Perhaps the I2C Slave is too slow in it's implementation, or the master sends too many requests, or needs to be paced better by the slave. Perhaps synchronization or flow could be better managed with GPIO/EXTI ?

[MM..1]

MCO cant generate sinewave, but you write I2C troyuble, and this type of interface cant have trouble with async clocks on normal I2C speeds.

Try solve your trouble other way.

[jim239955_st]

Sorry are you saying that my source of information was wrong and that an out of sync clock does not affect i2C performance between two MCU's? at present the I2C comms operates for a random time between 10 minutes and several days but then just stops. only a power cycle seems to clear the i2C again. no other functions of either MCU are affected.

[MM..1]

Yes out of sync clock does not affect i2C performance between two MCU's, by design.

[jim239955_st]

Tesla and MM Thanks guys for all your help. It is clearly more of an issue in the programming than I assumed. The main thing I can take from this thread is that we do not need to modify the board for a single clock source as that can not be the issue by design. I will halt this thread now as the conversation is moving towards I2C programming issues rather than clock issues. I will look into this a bit more and come back on a different thread when i can describe the issue a lot more thoroughly.

[Tesla DeLorean]

Suggested course of action

Instrument both sides of the transaction so you can debug/diagnose the flow. You want to do this independently of the debugger as that can be intrusive.

Have both sides capable of identifying the failing state, via timeout, identify a deadlock, etc allowing you to measure elapsed time and frequency of the issue.

Be able to signal the failure with a GPIO.

Use a logic analyzer to confine signals in a failure state, use the failure signal as a trigger.

Determine which side of the transaction seems to be to blame.

Try to remedy or address what the issue is.

Have the ability to retry or break the deadlock, keep metrics so you can see how often it occurs and the periodicity, check if the issue recurs

[jim239955_st]

ok will do Thank you so much for the advice!