I2C stops working with System Clock 168M on STM32F407

[XLei.3]

Hello,

I'm working on a STM32F407 board, and communicating with 6 I2C sensors which are scattered on the 3 I2C interfaces with 400K clock. Everything is fine if the system clock is set to 40MHZ. When I'm trying to change the sys clock to 168M, all I2C interfaces stop working. With some test, I have to slow down the I2C clock to 250K then the communication works fine. Do you have any idea why this happens?

Thanks,

Xiaofeng

[waclawek.jan]

So, with increasing system clock, did also TPCLK1 clock frequency increase?

How did you change the timing registers in I2C, i.e. what were the values in I2C_CCR, I2C_TRISE and I2C_FLTR registers, before and after the change?

JW

[XLei.3]

Thanks for the quick response.

To change the sys clock, I actually just set the 4 values with external HSE 8M clock: PLLM/N/P/Q. Previous change with 40M clock is: 4/80/4/4, and the new 168M clock settings are: 8/336/2/4.

Here are Register's values (FLTR not available for 407):

40M Clock with 400K I2C: CCR = 32777, TRISE = 4

168M Clock with 250K I2C: CCR=32824, TRISE=13

[waclawek.jan]

> FLTR not available for 407

Indeed - I'm currently working with 'F427, sorry for the confusion.

APB2 divider was 4 in both cases?

One more frequency-dependent register is I2C_CR2.FREQ - other than that, I don't know, sorry.

Also, I don't use the Fm mode, I use only 100kHz. Don't you need to set also the F/S bit in I2C_CCR?

JW

[XLei.3]

Yes, APB2 divider is same 2 for both cases, so APB2 peripheral clock is 20M with 40M sys clock, and 84M with 168M sys clock which is the maximum clock for PCLK2.

[XLei.3]

@Community member​  Thank you for your response. You remind me to check CCR:

"It must be a multiple of 10MHz to reach the

400 kHz maximum IÇC Fm mode clock."

Maybe this is the reason because current PCLK1 is 42M. I will change this to other value.

[XLei.3]

No lucks to change the system clock to 160M with PCLK1 40M and PCLK2 80M, maybe I still missed something. Will keep looking into it.

[Tesla DeLorean]

Perhaps look at the signal integrity from the bus side perspective.

Use a scope