I am using Flex I/O module on KL17 as I2C master. What I've noticed is that as long as my clock rate is set to 100 KHz or above, it is properly observed, but anything below 100 KHz I've tried results in unexpected clock rate.
To reproduce, use the SDK magnetometer sample (read_accel_value_transfer) with FRDM-KL27Z board.
Run the sample unmodified with I2C analyzer or oscilloscope attached and observe I2C clock running at 98 KHz
Now change I2C_BAUDRATE to 50000 (on line 51 in flexio_i2c_read_accel_value_transfer.c), compile and run.
Observed clock is now 462 KHz. Board fails to communicate with the accelerometer/magnetometer as a result.
If I set I2C_BAUDRATE to 90000, I get 1712 KHz (yes, 1.7 MHz)
Looking into the Flex I/O I2C master source one can see the problem:
timerDiv = srcClock_Hz / baudRate_Bps;
timerDiv = timerDiv / 2 - 1U;
If the baud rate is < 93.75 KHz, the 8-bit register overflows. To get lower baud rate the Flex I/O clock needs to run at lower speed (default is 48 MHz - same as core clock).
I think some sort of assert needs to be added there:
/* Set TIMCMP[7:0] = (baud rate divider / 2) - 1. */
assert((srcClock_Hz / masterConfig->baudRate_Bps) <= 512);
timerConfig.timerCompare = ((srcClock_Hz / masterConfig->baudRate_Bps) / 2 - 1);
I would agree with you. When customer is using KSDK drivers in very simple way (I mean, without "any" knowledge of dedicated peripheral) then it is clear this will make difficulties in the application development and some warning is required.
However, I will never recommend that way. Customer should know at least some basics about the periphery he wants to use and in such case it is clear that with 48MHz source clock it will be not possible to achieve dedicated lower baudrates. So, it is required to change source clock.
I think this is software bug, the Low byte of FLEXIO_TIMCMPn is used as a divider, the maximum value is 255, if the baudrate is low enough, the didvider will be out of range, the baudrate will be wrong. As you said, assert() instruction is needed.