I2C register map in stm32mp157f-dk2

[WLeun.3]

Hi all,

​

I am studying the pmic of stm32mp157f-dk2.

My ultimate goal is to write a device tree structure for other pmic chip like tps65 series to replace the stpmic

&i2c4{
 ...
	stusb1600@28{
 compatible = "st,stusb1600";
 reg = <0x28>;
 ...
 };
	pmic:stpmic@33{
	compatible = "st,stpmic1";
	reg = <0x33>;
 ...
 };
};

I am interested in how the reg variable(0x28 and 0x33) are determined. So I go through the data sheet of stm32mp157f.

In table 357, it suggests that 0x00-0x28 are used. As the device tree claim the stusb register should start with 0x28, their register are overlapping with each other.

But stusb1600 datasheet, table 16 suggests that 0x0-0x0a of stusb1600 is reserved.

Although their register are overlapping, they are reserved in stusb1600, so only the mp1 i2c are using those space.

So far, so good.

but for the stusb1600, it require up to 2Fh space. why are the pmic start with 0x33, Shouldn't the pmic register start with 28+2F=57?

I must be missing something important here.

Any clues?

Leung

​

​

​

[PatrickF]

Hi @WLeun.3​ ,

you cannot find this information in STM32MP157F Reference Manual as it relates to external components.

The 'reg' in this device tree context refer to external component address on the I2C bus.

See https://wiki.st.com/stm32mpu/wiki/I2C_device_tree_configuration#I-C2-B2C_devices_related_properties

0x28 and 0x33 are respectively the I2C address of the STUSB1600 and STPMIC1 as implemented on STM32MP157F-DK2 board. You could find this information in their respective documentation.

Regards,

In order to give better visibility on the answered topics, please click on 'Select as Best' on the reply which solved your issue or answered your question. See also 'Best Answers'

[WLeun.3]

Hi @PatrickF​ ,

I have a follow up question.

Now my device tree become

&i2c5{
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&i2c5_pins_mx>;
	pinctrl-1 = <&i2c5_sleep_pins_mx>;
	status = "okay";
 
	/* USER CODE BEGIN i2c5 */
	tps65023@48 {
		compatible = "ti,tps65023";
		reg = <0x48>;
		status = "okay";
		regulators {
			VDCDC1 {
				regulator-name = "vdd_mpu";
				regulator-always-on;
				regulator-min-microvolt = <1200000>;
				regulator-max-microvolt = <1200000>;
			};
 
			VDCDC2 {
				regulator-name = "vdd_core";
				regulator-always-on;
				regulator-min-microvolt = <3300000>;
				regulator-max-microvolt = <3300000>;
			};
 
			VDCDC3 {
				regulator-name = "vdd_io";
				regulator-always-on;
				regulator-min-microvolt = <1800000>;
				regulator-max-microvolt = <1800000>;
			};
 
			LDO1 {
				regulator-name = "vdd_usb18";
				regulator-always-on;
				regulator-min-microvolt = <1800000>;
				regulator-max-microvolt = <1800000>;
			};
 
			LDO2 {
				regulator-name = "vdd_usb33";
				regulator-always-on;
				regulator-min-microvolt = <3300000>;
				regulator-max-microvolt = <3300000>;
			};
		};
	};
	/* USER CODE END i2c5 */
};

I copy most of the stuff from https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/tps65023.txt

With this device tree and set REGULATOR_TPS65023=Y

I expect to see something like UU in the 0x48 field of i2cdetect

However, I see nothing

 

Any clues what am I missing?

Regards,

Leung

[PatrickF]

Hi @WLeun.3​ ,

not DT expert, but maybe look at :

https://wiki.st.com/stm32mpu/wiki/I2C_device_tree_configuration#DT_configuration_-28board_level-29

Maybe missing some timing information e.g.:

	i2c-scl-rising-time-ns = <185>;
	i2c-scl-falling-time-ns = <20>;
	clock-frequency = <400000>;

Did you configure the right pins (I2C5_SCL on PA11 AF4 and I2C5_SDA and PA12 AF4) ?

cat /sys/kernel/debug/pinctrl/soc:pin-controller@50002000/pinconf-pins | grep I2C5

Is your external device connected on right signals ?

Did you see activity on the I2C lanes when you do i2cdetect ?

I think the 'regulators' are not needed here except if you need a specific supply on your device (which seems not the case here)

Regards.

[WLeun.3]

Hi @PatrickF​ ,

Thanks for your advices.

The I2C lanes do have activity when I do i2cdetect, which suggests the dt are fine, and it is more like a hardware issue.

Finally I found that I have not ground the evaluation kit and my testing board properly, which make the i2c signal floating.

Regards,

Leung