Hi,
in TwoWire's setClock() function, there is a clock divisor calculation by calling R_FSP_SystemClockHzGet() with BSP_FEATURE_SCI_CLOCK.
First, the result is only used in the non-SCI path - the constant referring specifically to an SCI clock, I wonder if it is even suitable to use for the i2c clock?
Second, in other places that use R_FSP_SystemClockHzGet() I read that it retrieves the "current" value, indicating that this function's return value can change at runtime? Does this mean that the cks_value value depends on external factors when Wire is initialized?
Is there a source for these calculations and values used for brl_value, brl_value and cks_value added in this commit by @facchinm ?
Thank you
EDIT: In Renesas RA4M1 Group "User's Manual: Hardware" on page 848 in table 29.8 should be the relevant table for SCLE=1* and NFE=1. For normal speed, brl_value should be 15, brl_value should be 12 and cks_value should be 3.
Maybe R_FSP_SystemClockHzGet() was originally added for a reason and those values must be adapted based on some clocking discrepancies but that is outside my expertise.
*) note that although the comment block above the ICFER register configuration in r_iic_master.c says otherwise, the SCL synchronous circuit enable bit is actually set via IIC_MASTER_FUNCTION_ENABLE_INIT_SETTINGS being 0x77, as it should be according to the manual
EDIT 2: I was looking into this issue because I had occasional and unexplainable i2c transaction aborts with my Arduino Uno R4 WIFI resulting in a stuck bus. After changing the values according to the user's manual as mentioned above, the problem was fixed. Reverting back to the current values immediately triggered an abort after a few minutes of runtime. I switched back and forth and observe a consistent behaviour. Strangely, it does not seem to be a problem for other people, so it's still a bit of a mystery.
Hi,
in
TwoWire'ssetClock()function, there is a clock divisor calculation by callingR_FSP_SystemClockHzGet()withBSP_FEATURE_SCI_CLOCK.First, the result is only used in the non-SCI path - the constant referring specifically to an SCI clock, I wonder if it is even suitable to use for the i2c clock?
Second, in other places that use
R_FSP_SystemClockHzGet()I read that it retrieves the "current" value, indicating that this function's return value can change at runtime? Does this mean that thecks_valuevalue depends on external factors when Wire is initialized?Is there a source for these calculations and values used for
brl_value,brl_valueandcks_valueadded in this commit by @facchinm ?Thank you
EDIT: In Renesas RA4M1 Group "User's Manual: Hardware" on page 848 in table 29.8 should be the relevant table for SCLE=1* and NFE=1. For normal speed,
brl_valueshould be 15,brl_valueshould be 12 andcks_valueshould be 3.Maybe
R_FSP_SystemClockHzGet()was originally added for a reason and those values must be adapted based on some clocking discrepancies but that is outside my expertise.*) note that although the comment block above the ICFER register configuration in r_iic_master.c says otherwise, the SCL synchronous circuit enable bit is actually set via
IIC_MASTER_FUNCTION_ENABLE_INIT_SETTINGSbeing0x77, as it should be according to the manualEDIT 2: I was looking into this issue because I had occasional and unexplainable i2c transaction aborts with my Arduino Uno R4 WIFI resulting in a stuck bus. After changing the values according to the user's manual as mentioned above, the problem was fixed. Reverting back to the current values immediately triggered an abort after a few minutes of runtime. I switched back and forth and observe a consistent behaviour. Strangely, it does not seem to be a problem for other people, so it's still a bit of a mystery.