i2c almost working for me, was Re: i2c still not working for me

[Daniel Braniss]

> On 18 Apr 2019, at 17:19, Ian Lepore <ian at freebsd.org> wrote:
> 
> On Thu, 2019-04-18 at 10:12 +0300, Daniel Braniss wrote:
>>> On 17 Apr 2019, at 23:26, Emmanuel Vadot <manu at bidouilliste.com>
>>> wrote:
>>> 
>>> On Tue, 16 Apr 2019 09:16:02 +0300
>>> Daniel Braniss <danny at cs.huji.ac.il <mailto:danny at cs.huji.ac.il>>
>>> wrote:
>>> 
>>>> 
>>>> 
>>>>> On 11 Apr 2019, at 09:56, Daniel Braniss <danny at cs.huji.ac.il>
>>>>> wrote:
>>>>> 
>>>>> if no device is connected, I2CRDWR hangs, 
>>>>> it also happens with i2c(8) -s, only reboot helps.
>>>>> 
>>>>> ichb1: twsi_reset: Using IIC_FASTEST/UNKNOWN mode with speed
>>>>> param=2a
>>>>> iichb1: TWSI_WRITE: Writing 0 to 18
>>>>> iichb1: TWSI_WRITE: Writing 2a to 14
>>>>> iichb1: TWSI_WRITE: Writing 40 to c
>>>>> iichb1: TWSI_WRITE: Writing c4 to c
>>>>> iichb1: twsi_transfer: transmitting 2 messages
>>>>> iichb1: TWSI_READ: read f8 from 10
>>>>> iichb1: twsi_transfer: status=f8
>>>>> iichb1: twsi_transfer: msg[0] flags: 0
>>>>> iichb1: twsi_transfer: msg[0] len: 9
>>>>> iichb1: TWSI_WRITE: Writing e4 to c
>>>>> 
>>>>> and now it?s hung
>>>> 
>>>> [?]
>>> 
>>> I don't see that on my OrangePi One or Pine64-LTS.
>> 
>> well, mine is are Nanopi Neo, maybe it’s a dts issue?
>> I also have a orangepi-zero but it will take me some time to make
>> a sdcard

I managed to boot my OrangePi Zero, and i2c -s has no issues, does not hang.
still, with the latest (r346368) my NanoPi Neo hangs when no i2c device is present,
so what is the difference? or where can I look?


>>> 
>>>> 
>>>> even with a working device, this happens sometimes:
>>>> 
>>>> my app gets ENXIO from the ioctl(fd, I2CRDWR, &data) and on the
>>>> console:
>>>> ?
>>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 29 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 29 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 29 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 29 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 38 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 29 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 29 on CPU2
>>>> gic0: Spurious interrupt detected: last irq: 29 on CPU2
>>>> 
>>>> the good news: my app is killable :-)
>>> 
>>> I would need more details for this.
>> 
>> it was caused by i2c issues - the cable was a bit too long.
>> BTW, does changing the frequency work? ie dev.iicbus.0.frequency
> 
> It looks like that driver does not honor the frequency sysctl/tunable.

> 
> You can often compensate for a too-long cable by adding some stronger
> pullups.  It's typical for a SOM to have pullups in the 4.7K range on
> i2c.  You can add your own 1K pullups to see if that helps the rise
> times on the bus.

well, at the moment it works ok with a 6m cable, i’ll try your suggestion soon.

> 
> -- Ian
> 


cheers,
	danny