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.​

[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]

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?

[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.

[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]

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

[jim239955_st]

Sounds like you have a lot more experience at this than me or my original source of information. The master MCU is an STM32F401RBT6 and the slave is STM32F407VGT6. I have been struggling with this as it was originally someone elses design and project and i have been asked to take it over when they left and cut off from it. It is unfortunately not very well annotated.

It looks like both MCU's have 8MHz crystals, and internally doubled to 16MHz.

The only note the previous developer left was that he had 'occasional issues' where the three byte messages that Master was being sent to the slave and the slave only received 2 bytes so the I2C was effectively blocked waiting for the third byte to be sent. I ran that past my colleague and he said 'clocks out of sync' use one source.

[jim239955_st]

ok thank you for putting me straight.

[Tesla DeLorean]

I'm really not party to what the information source was observing, or what the underlying issue is.

To be honest it seems like some broken expectations on one or other end of the connection/transaction is likely the bigger issue,

Require synchronous clocks and phase alignment in an I2C implementation seems to be a significant stretch.

Perhaps you can expand on the use case, and failure modes?

Between two processors a 8 or 9-bit UART implementation should be able to get to 460800 baud (or 400K / 500K if preferred), without a lot of clock level sync. Or a comms link that is inherently synchronous.