arduino / arduino/ArduinoCore-renesas

Clarify/Fix hardware clock settings in TwoWire

Open
#554 0 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.