Re: Debugging i2c : i2cdetect cant detect a device on i2c line

Re: Debugging i2c : i2cdetect cant detect a device on i2c line

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]

[also Cc: devicetree and ARM folks]

On Thu, Sep 07, 2023 at 08:21:44AM +0530, Raul Piper wrote:
> Hello ,
> I am trying to detect an i2c device A on i2c1 line on  one of the Arm
> Cortex A7 platform but not able to see any device on a given address (
> 0x3d) .
> 
> Is there any parameters of i2c which i can change like rise/fall time
> , timeout etc in a device tree or kernel source and re test it?
> I have tried changing the i2c speed from 100KHz to 400 KHz  but no success.
> I have even tried removing the 1.5K pull ups on the i2c lines but no result.
> 
> So I wanted to know on what factors i2cdetect may not probe the device
> or show it on the hex dump.
> What parameters of i2c driver i can tinker and where? Is Platform dts
> is the only file i can modify and test with?
> Kernel is 5.51 .

Do you mean v5.15.y stable series?

> There are other 2-3 devices on the same lines which responds to
> i2cdetect with correct address but not this device (0x3D) .
> Its i2c address is also different from the current devices.
> 

Specifically, what device do you have this issue with?

Confused...

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Debugging i2c : i2cdetect cant detect a device on i2c line

[Russell King (Oracle)]

On Thu, Sep 07, 2023 at 08:36:32PM +0700, Bagas Sanjaya wrote:
> [also Cc: devicetree and ARM folks]
> 
> On Thu, Sep 07, 2023 at 08:21:44AM +0530, Raul Piper wrote:
> > Hello ,
> > I am trying to detect an i2c device A on i2c1 line on  one of the Arm
> > Cortex A7 platform but not able to see any device on a given address (
> > 0x3d) .
> > 
> > Is there any parameters of i2c which i can change like rise/fall time
> > , timeout etc in a device tree or kernel source and re test it?
> > I have tried changing the i2c speed from 100KHz to 400 KHz  but no success.
> > I have even tried removing the 1.5K pull ups on the i2c lines but no result.

Honestly, from this description, I'm wondering if this posting is a joke.

I2C is entirely _reliant_ on pull-ups. It's a wire-or bus, and the
logic 1 state is created by no device pulling the signal low, thereby
allowing the pull-up resistor to pull the line to the logic 1 state.

The pull-up must be the correct strength for the devices on the bus.
If it is too strong, then a driver may not be able to pull the signal
sufficiently low for other devices to register it as a logic 0.

Conversely, the pull-up must be strong enough so that the rise-time
of the signal is sufficient to register as a logic 1.

If it's a problem with the rise time, then increasing the clock rate
will just make the situation worse.

So, if other devices work on the bus, it could be that the Vil
threshold of this device is not being achieved, whereas the other
devices are happy. Therefore, I would suggest you study the data
sheets of the device that isn't being detected.

Lastly, if the undetectable device has a reset line, it's possible
that the device isn't responding because it's being held in reset.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: Debugging i2c : i2cdetect cant detect a device on i2c line

[Raul Piper]

On Thu, Sep 7, 2023 at 9:47 PM Lucas Tanure <tanure@linux.com> wrote:
>
>
>
> On Thu, 7 Sept 2023, 14:56 Russell King (Oracle), <linux@armlinux.org.uk> wrote:
>>
>> On Thu, Sep 07, 2023 at 08:36:32PM +0700, Bagas Sanjaya wrote:
>> > [also Cc: devicetree and ARM folks]
>> >
>> > On Thu, Sep 07, 2023 at 08:21:44AM +0530, Raul Piper wrote:
>> > > Hello ,
>> > > I am trying to detect an i2c device A on i2c1 line on  one of the Arm
>> > > Cortex A7 platform but not able to see any device on a given address (
>> > > 0x3d) .
>> > >
>> > > Is there any parameters of i2c which i can change like rise/fall time
>> > > , timeout etc in a device tree or kernel source and re test it?
>> > > I have tried changing the i2c speed from 100KHz to 400 KHz  but no success.
>> > > I have even tried removing the 1.5K pull ups on the i2c lines but no result.
>>
>> Honestly, from this description, I'm wondering if this posting is a joke.
>>
>> I2C is entirely _reliant_ on pull-ups. It's a wire-or bus, and the
>> logic 1 state is created by no device pulling the signal low, thereby
>> allowing the pull-up resistor to pull the line to the logic 1 state.
>>
>> The pull-up must be the correct strength for the devices on the bus.
>> If it is too strong, then a driver may not be able to pull the signal
>> sufficiently low for other devices to register it as a logic 0.
>>
>> Conversely, the pull-up must be strong enough so that the rise-time
>> of the signal is sufficient to register as a logic 1.
>>
>> If it's a problem with the rise time, then increasing the clock rate
>> will just make the situation worse.

Where can I change this time? Can you please provide example of some
device/device tree?

>>
>> So, if other devices work on the bus, it could be that the Vil
>> threshold of this device is not being achieved, whereas the other
>> devices are happy. Therefore, I would suggest you study the data
>> sheets of the device that isn't being detected.
What Vil threshold? I checked the power supply to this device and it
is ~3.3 V as expected.

>>
>> Lastly, if the undetectable device has a reset line, it's possible
>> that the device isn't responding because it's being held in reset.
The device is fine, I am sure about it. As the device provides data on
USART as well and I am getting it.
>
> Please try to use an logic analyser like saleae logic.
> Probe the i2c bus, reset line, power lines, pins that set the i2c address for the device.
> Can tell us which device it is?

Its a GPS sensor(still under development) .Logic Analyser gives NACK
on the given address.
I may be using the wrong pull ups value which i am checking.But from
software point of view is there a Device tree setting to enable the
internal pull ups or adjust the rise/fall time as said above.

>
>
>
>> --
>> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
>> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Debugging i2c : i2cdetect cant detect a device on i2c line

[Russell King (Oracle)]

On Thu, Sep 07, 2023 at 10:38:10PM +0530, Raul Piper wrote:
> On Thu, Sep 7, 2023 at 9:47 PM Lucas Tanure <tanure@linux.com> wrote:
> >
> >
> >
> > On Thu, 7 Sept 2023, 14:56 Russell King (Oracle), <linux@armlinux.org.uk> wrote:
> >>
> >> On Thu, Sep 07, 2023 at 08:36:32PM +0700, Bagas Sanjaya wrote:
> >> > [also Cc: devicetree and ARM folks]
> >> >
> >> > On Thu, Sep 07, 2023 at 08:21:44AM +0530, Raul Piper wrote:
> >> > > Hello ,
> >> > > I am trying to detect an i2c device A on i2c1 line on  one of the Arm
> >> > > Cortex A7 platform but not able to see any device on a given address (
> >> > > 0x3d) .
> >> > >
> >> > > Is there any parameters of i2c which i can change like rise/fall time
> >> > > , timeout etc in a device tree or kernel source and re test it?
> >> > > I have tried changing the i2c speed from 100KHz to 400 KHz  but no success.
> >> > > I have even tried removing the 1.5K pull ups on the i2c lines but no result.
> >>
> >> Honestly, from this description, I'm wondering if this posting is a joke.
> >>
> >> I2C is entirely _reliant_ on pull-ups. It's a wire-or bus, and the
> >> logic 1 state is created by no device pulling the signal low, thereby
> >> allowing the pull-up resistor to pull the line to the logic 1 state.
> >>
> >> The pull-up must be the correct strength for the devices on the bus.
> >> If it is too strong, then a driver may not be able to pull the signal
> >> sufficiently low for other devices to register it as a logic 0.
> >>
> >> Conversely, the pull-up must be strong enough so that the rise-time
> >> of the signal is sufficient to register as a logic 1.
> >>
> >> If it's a problem with the rise time, then increasing the clock rate
> >> will just make the situation worse.
> 
> Where can I change this time? Can you please provide example of some
> device/device tree?

You can't directly. The rise time is a function of the capacitive
loading on the lines and the pull-up resistor. It's not a software
parameter.

> >> So, if other devices work on the bus, it could be that the Vil
> >> threshold of this device is not being achieved, whereas the other
> >> devices are happy. Therefore, I would suggest you study the data
> >> sheets of the device that isn't being detected.
> What Vil threshold? I checked the power supply to this device and it
> is ~3.3 V as expected.

This makes me convinced that you're not familiar with electronics.

Vil is a pretty standard parameter in all digital logic for "Voltage,
input, low" - the voltage at which it is guaranteed that the device
will see a logic 0 signal on its input.

If I draw a diagram illustrating the voltage levels on an input,
top is the supply voltage, bottom is ground, then most are:

	+------+	<--- Vcc (supply voltage)
	|      |	<--- Within this region, it is guaranteed that
	|      |	     the device will see a logic 1
	+------+	<--- Vih (input high)
	|//////|
	|\\\\\\|	<--- Within this region, the value that the
	|//////|	     device sees is indeterminant
	|\\\\\\|
	+------+	<--- Vil (input low)
	|      |
	|      |
	+------+	<--- Ground (0V)

So, if the voltage on the SDA and SCL pins does not reach Vil or below,
there is no guarantee that the device will see a logic 0 on its input,
and it either won't work, it may sporadically work. Basically, Vil is
the threshold voltage at which the manufacturer _guarantees_ that the
device will see a logic 0, and Vih is the threshold voltage at which
the manufacturer _guarantees_ that the device will see a logic 1.

Both these parameters will be specified in the data sheet, possibly
as a function of supply voltage.

> >> Lastly, if the undetectable device has a reset line, it's possible
> >> that the device isn't responding because it's being held in reset.
> The device is fine, I am sure about it. As the device provides data on
> USART as well and I am getting it.
> >
> > Please try to use an logic analyser like saleae logic.
> > Probe the i2c bus, reset line, power lines, pins that set the i2c address for the device.
> > Can tell us which device it is?
> 
> Its a GPS sensor(still under development) .Logic Analyser gives NACK
> on the given address.

Which means either the device is not seeing the logic levels necessary
to receive the address, or maybe if this is a prototype I2C device,
maybe it has a bug in its address matching logic, or the address is
incorrectly set.

I'd first be checking that the Vih and Vil for this device are being
achieved by putting an oscilloscope on its input pin and comparing
that with the device specification.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: Debugging i2c : i2cdetect cant detect a device on i2c line

[Russell King (Oracle)]

On Thu, Sep 07, 2023 at 05:17:47PM +0100, Lucas Tanure wrote:
> On Thu, 7 Sept 2023, 14:56 Russell King (Oracle), <linux@armlinux.org.uk>
> wrote:
> 
> > On Thu, Sep 07, 2023 at 08:36:32PM +0700, Bagas Sanjaya wrote:
> > > [also Cc: devicetree and ARM folks]
> > >
> > > On Thu, Sep 07, 2023 at 08:21:44AM +0530, Raul Piper wrote:
> > > > Hello ,
> > > > I am trying to detect an i2c device A on i2c1 line on  one of the Arm
> > > > Cortex A7 platform but not able to see any device on a given address (
> > > > 0x3d) .
> > > >
> > > > Is there any parameters of i2c which i can change like rise/fall time
> > > > , timeout etc in a device tree or kernel source and re test it?
> > > > I have tried changing the i2c speed from 100KHz to 400 KHz  but no
> > success.
> > > > I have even tried removing the 1.5K pull ups on the i2c lines but no
> > result.
> >
> > Honestly, from this description, I'm wondering if this posting is a joke.
> >
> > I2C is entirely _reliant_ on pull-ups. It's a wire-or bus, and the
> > logic 1 state is created by no device pulling the signal low, thereby
> > allowing the pull-up resistor to pull the line to the logic 1 state.
> >
> > The pull-up must be the correct strength for the devices on the bus.
> > If it is too strong, then a driver may not be able to pull the signal
> > sufficiently low for other devices to register it as a logic 0.
> >
> > Conversely, the pull-up must be strong enough so that the rise-time
> > of the signal is sufficient to register as a logic 1.
> >
> > If it's a problem with the rise time, then increasing the clock rate
> > will just make the situation worse.
> >
> > So, if other devices work on the bus, it could be that the Vil
> > threshold of this device is not being achieved, whereas the other
> > devices are happy. Therefore, I would suggest you study the data
> > sheets of the device that isn't being detected.
> >
> > Lastly, if the undetectable device has a reset line, it's possible
> > that the device isn't responding because it's being held in reset.
> >
> Please try to use an logic analyser like saleae logic.
> Probe the i2c bus, reset line, power lines, pins that set the i2c address
> for the device.
> Can tell us which device it is?

I assume you are replying to Bagas? Please me it clear in future.
Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!