arduino / arduino/ArduinoCore-renesas
Clarify/Fix hardware clock settings in TwoWire
- Dominant language
- C
- Stars
- 193
- Forks
- 112
- PR merge metrics
- No merged PRs in 30d
Description
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](https://github.com/arduino/ArduinoCore-renesas/commit/3c4642661cb3a0d1f9046ca80b6a26b9c475b969) by @facchinm ?
Thank you
**EDIT**: In Renesas RA4M1 Group "[User's Manual: Hardware](https://www.renesas.com/en/document/mah/renesas-ra4m1-group-users-manual-hardware?r=1054146)" 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](https://github.com/renesas/fsp/blob/master/ra/fsp/src/r_iic_master/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](https://forum.arduino.cc/t/mysterious-random-i2c-fault-across-different-devices/1455971/16), so it's still a bit of a mystery.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start in TwoWire's setClock() and compare the R_FSP_SystemClockHzGet/BSP_FEATURE_SCI_CLOCK calculation with the values in the Renesas RA4M1 hardware manual, table 29.8, and the referenced commit. Check r_iic_master.c and the ICFER initialization note for context. Done means the clock settings are justified or corrected and the reported I2C abort behavior is verified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, cpp
- Domain
- embedded-iot
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100