nanopi/allwinner i2c not working.

Daniel Braniss danny at cs.huji.ac.il
Wed Oct 7 07:54:59 UTC 2020



> On 7 Oct 2020, at 10:21, Daniel Braniss <danny at cs.huji.ac.il> wrote:
> 
> 
> 
>> On 7 Oct 2020, at 09:32, Andriy Gapon <avg at FreeBSD.org> wrote:
>> 
>> On 06/10/2020 23:29, Daniel Braniss wrote:
>>> 
>>> 
>>>> On 6 Oct 2020, at 17:22, Andriy Gapon <avg at FreeBSD.org
>>>> <mailto:avg at FreeBSD.org>> wrote:
>>>> 
>>>> On 06/10/2020 17:00, Daniel Braniss wrote:
>>>>> not too proud of it, but i’ll make it available.
>>>>> it’s in https://www.cs.huji.ac.il/~danny/elockc.tar.bz
>>>>> look in i2c.c
>>>>> 
>>>>> in any case it works fine in 12.1.
>>>> 
>>>> And it looks good to me as well.
>>>> Could you please collect twsi debug output again?
>>>> In head you do not need to recompile, you can just set hw.i2c.twsi_debug.
>>> i did have to recompile
>> 
>> Oh, I thought I committed that change, but now I see that I have not.
>> It is a part of D26049.
>> 
>>> iichb0: twsi_calc_baud_rate: Bus clock is at 24000000
>>> iichb0: twsi_reset: Using clock param=59
>>> iichb0: TWSI_WRITE: Writing 0 to 18
>>> iichb0: TWSI_WRITE: Writing 59 to 14
>>> iichb0: TWSI_WRITE: Writing 40 to c
>>> iichb0: twsi_calc_baud_rate: Bus clock is at 24000000
>>> iichb0: twsi_reset: Using clock param=59
>>> iichb0: TWSI_WRITE: Writing 0 to 18
>>> iichb0: TWSI_WRITE: Writing 59 to 14
>>> iichb0: TWSI_WRITE: Writing 40 to c
>>> iichb0: TWSI_WRITE: Writing c4 to c
>>> iichb0: twsi_transfer: transmitting 2 messages
>>> iichb0: TWSI_READ: read f8 from 10
>>> iichb0: twsi_transfer: status=f8
>>> iichb0: twsi_transfer: msg 0 is 9 bytes long
>>> iichb0: twsi_transfer: msg 1 is 7 bytes long
>>> iichb0: TWSI_WRITE: Writing e4 to c
>>> iichb0: twsi_intr: Got interrupt Current msg=0
>>> iichb0: TWSI_READ: read 8 from 10
>>> iichb0: TWSI_READ: read cc from c
>>> iichb0: twsi_intr: reg control=cc
>>> iichb0: twsi_intr: Send the address (48)iichb0: TWSI_WRITE: Writing 48 to 8
>> 
>> Does that address (0x24 / 0x48 in 7-/8-bit representations) look correct?
> 
> 100% correct
> 
>> 
>>> iichb0: TWSI_WRITE: Writing c4 to c
>>> iichb0: twsi_intr: Refresh reg_control
>>> iichb0: TWSI_WRITE: Writing cc to c
>>> iichb0: twsi_intr: Done with interrupts
>>> 
>>> iichb0: twsi_intr: Got interrupt Current msg=0
>>> iichb0: TWSI_READ: read 20 from 10
>>> iichb0: TWSI_READ: read cc from c
>>> iichb0: twsi_intr: reg control=cc
>>> iichb0: twsi_intr: No ack received after transmitting the address
>> 
>> The controller says that the device did not acknowledge its address.
>> In other words, no device responded to the slave address.
> 
> but i2c -s 
>> 
>>> iichb0: twsi_intr: Refresh reg_control
>>> iichb0: twsi_transfer: pause finish
>>> iichb0: TWSI_WRITE: Writing 8 to c
>>> iichb0: twsi_transfer: Error, aborting (2)
>>> iichb0: twsi_intr: Done with interrupts
>>> 
>>> iichb0: TWSI_WRITE: Writing 0 to c
>>> iichb0: TWSI_READ: read 30 from 10
>>> iichb0: twsi_transfer: status=30
>>> iichb0: TWSI_WRITE: Writing 0 to c
>>> iichb0: TWSI_READ: read 30 from 10
>>> iichb0: twsi_transfer: status=30
>>> iichb0: TWSI_WRITE: Writing c4 to c
>>> iichb0: twsi_transfer: transmitting 2 messages
>>> iichb0: twsi_intr: Got interrupt Current msg=0
>>> iichb0: TWSI_READ: read 30 from 10
>>> iichb0: TWSI_READ: read 30 from 10
>>> iichb0: twsi_transfer: status=30
>>> iichb0: TWSI_READ: read cc from c
>>> iichb0: twsi_transfer: msg 0 is 9 bytes long
>>> iichb0: twsi_intr: reg control=cc
>>> iichb0: twsi_transfer: msg 1 is 7 bytes long
>>> 
>>> iichb0: twsi_intr: status=30 hot handled
>>> iichb0: TWSI_WRITE: Writing e4 to c
>>> iichb0: twsi_intr: Refresh reg_control
>>> iichb0: twsi_transfer: pause finish
>>> iichb0: TWSI_WRITE: Writing 8 to c
>>> iichb0: twsi_transfer: Error, aborting (1)
>>> iichb0: twsi_intr: Done with interrupts
>>> 
>>> iichb0: TWSI_WRITE: Writing 0 to c
>>> iichb0: TWSI_READ: read 10 from 10
>>> iichb0: twsi_transfer: status=10
>>> iichb0: TWSI_WRITE: Writing 0 to c
>>> iichb0: TWSI_READ: read 10 from 10
>>> iichb0: twsi_transfer: status=10
>> 
>> The rest reads like gibberish because the driver did not stop the controller
>> after the NACK (also, possibly some log messages were omitted from your email).
>> 
>> I'd recommend once again to give https://reviews.freebsd.org/D26049 a try.
>> I've just rebased it on the latest head, so it should apply cleanly.
> 
> i just downloaded it and will try - the sysctl for hw. is there.
> 
> (i did a git to get the latest current, i’ll try doing an svn update later -its bloody slow)
>> 
>> But as I said earlier, from the debug log it seems that the problem is either
>> with the slave address or with the hardware (wiring, etc).
> 
> the hardware is fine, running 12.1 on it works ok.
> and also i2c -s finds it.
> 
> 
>> It's also possible that that was a transient condition.
> 
> not really, it seems to me some timming issue.
> 
> after a power cycle, and with debug on, all is working.
> turning off debug only i2c -s works.
> 
> in any case will try the D26049 now.
> 


with D26049:
i2s -s works with and without debug

my test runs ok with debug on, but failed with debug off.
timing issue?

thanks,
	danny



More information about the freebsd-arm mailing list