Is it just a lack of consistency in HAL drivers?

[RZasa.1]

I have my clock configured to external crystal 80MHz but accidentally I connected another board without crystal. STM32 started OK using internal oscillator at 4 MHz - HAL_Delay works fine, UART works fine but I2C is very slow. It looks like I2C HAL library does not see actual clock while UART does. Does this inconsistency have some sensible explanation?

[TDK]

Well if it's configured for HSE and there is no HSE, what exactly are you expecting? Seems like an inconsistent/incorrect clock speed is the best you could hope for in that circumstance.

I would like to see this 80 MHz crystal you're using.

[RZasa.1]

Sorry, I meant 8 MHz crystal but system clock set to 80 MHz. Both UART and I2C are using PCLK1 but only UART is working at correct speed. It looks like UART library is setting speed based on detected clock but I2C library is setting speed based on expected clock speed.

[TDK]

HAL is open source, you can jump to the initialization functions to inspect. On the STM32F4 family, both UART and I2C retrieve the current clock settings when initializing the clock.

https://github.com/STMicroelectronics/STM32CubeF4/blob/2d5b78e2da98fb44e028d87f4ff815427991affc/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_i2c.c#L498

https://github.com/STMicroelectronics/STM32CubeF4/blob/2d5b78e2da98fb44e028d87f4ff815427991affc/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_uart.c#L3100

[RZasa.1]

Thanks for response. On STM32L476RG it works differently. For I2C value calculated by CubeMX is simply loaded into TIMINGR register of I2C regardless of actual clock settings:

hi2c->Instance->TIMINGR = hi2c->Init.Timing & TIMING_CLEAR_MASK;

..... and that's it.

For UART clock is retrieved by HAL_RCC_GetSysClockFreq() , baud rate calculated, and then loaded into BRR.

So it is also different from one family to another. That is why I called it inconsistency in the first place.

[TDK]

Next time, include your chip family in the post. There are over 1700 different STM32 chips.