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