Debugging i2c : i2cdetect cant detect a device on i2c line

[Lucas Tanure]

On Thu, 7 Sept 2023, 18:08 Raul Piper, <raulpblooper at gmail.com> wrote:

> On Thu, Sep 7, 2023 at 9:47 PM Lucas Tanure <tanure at linux.com> wrote:
> >
> >
> >
> > On Thu, 7 Sept 2023, 14:56 Russell King (Oracle), <linux at 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.
>
Read a little about the i2c protocol and check the signal levels of the i2c
lines.
In my experience you can understand the problem by just looking at the
signal levels if understand a little bit of i2c protocol.
Use the digital and analogue parts of you logic analyser.


> >
> >
> >
> >> --
> >> 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 at kernelnewbies.org
> >> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20230907/b8547d79/attachment-0001.html>