From: peda@lysator.liu.se (Peter Rosin)
To: linux-arm-kernel@lists.infradead.org
Subject: Regression: at24 eeprom writing
Date: Tue, 6 Oct 2015 18:41:16 +0200 [thread overview]
Message-ID: <5613F9AC.3090609@lysator.liu.se> (raw)
In-Reply-To: <CAH9NwWdv=JGGoy4JaGf77v=Z70Ms1ieeKGXNcW2weFaR2wy9+g@mail.gmail.com>
On 2015-10-05 08:16, Christian Gmeiner wrote:
> Hi Peter.
>
> Sorry for the late answer - I am currently on my way to Dublin. Maybe
> it helps if you enable
> I2C_DEBUG_CORE and I2C_DEBUG_BUS. In theory you should see a little
> bit better what
> happens on the bus.
Good suggestion. I did a new run (vanilla 4.2), and this is what I saw on
the bus this time:
[0.00000] S W50 0x00 "product = 1-776-" P
[0.00184] S W50 NACK P
[0.00195] S W50 NACK P
[0.02027] S W50 0x10 ACK...
[0.04035] ...ACK 0x10 "3.0\n" P
[0.04100] S W50 NACK P
[0.04111] S W50 NACK P
[0.06032] S W50 "serial = 380" P
[0.06174] S W50 NACK P
[0.06185] S W50 NACK P
[0.08032] S W50 0x20 ACK...
[0.10034] ...ACK 0x20 "000002\n" P
[0.10127] S W50 NACK P
[0.10138] S W50 NACK P
[0.12039] S W50 0x27 " " P
[0.12155] S W50 NACK P
[0.12166] S W50 NACK P
[0.14040] S W50 0x30 " " P
[0.14219] S W50 NACK P
[0.14230] S W50 NACK P
[0.16042] S W50 0x40 " " P
...
And this is the corresponding part of the log from the same run
(offset ~197.79 s):
[ 197.790000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=17
[ 197.790000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.790000] at91_i2c f0014000.i2c: transfer: write 17 bytes.
[ 197.800000] at91_i2c f0014000.i2c: transfer complete
[ 197.800000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=5
[ 197.800000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.800000] at91_i2c f0014000.i2c: transfer: write 5 bytes.
[ 197.800000] at91_i2c f0014000.i2c: wrote 0x10, to go 4
[ 197.800000] at91_i2c f0014000.i2c: wrote 0x33, to go 3
[ 197.800000] at91_i2c f0014000.i2c: received nack
[ 197.820000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=5
[ 197.820000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.820000] at91_i2c f0014000.i2c: transfer: write 5 bytes.
[ 197.820000] at91_i2c f0014000.i2c: wrote 0x10, to go 4
[ 197.820000] at91_i2c f0014000.i2c: received nack
[ 197.840000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=5
[ 197.840000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.840000] at91_i2c f0014000.i2c: transfer: write 5 bytes.
[ 197.840000] at91_i2c f0014000.i2c: wrote 0x10, to go 4
[ 197.840000] at91_i2c f0014000.i2c: wrote 0x33, to go 3
[ 197.840000] at91_i2c f0014000.i2c: wrote 0x2e, to go 2
[ 197.840000] at91_i2c f0014000.i2c: wrote 0x30, to go 1
[ 197.840000] at91_i2c f0014000.i2c: wrote 0xa, to go 0
[ 197.840000] at91_i2c f0014000.i2c: transfer complete
[ 197.840000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=13
[ 197.840000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.840000] at91_i2c f0014000.i2c: transfer: write 13 bytes.
[ 197.840000] at91_i2c f0014000.i2c: received nack
[ 197.860000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=13
[ 197.860000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.860000] at91_i2c f0014000.i2c: transfer: write 13 bytes.
[ 197.860000] at91_i2c f0014000.i2c: transfer complete
[ 197.860000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=8
[ 197.860000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.860000] at91_i2c f0014000.i2c: transfer: write 8 bytes.
[ 197.860000] at91_i2c f0014000.i2c: wrote 0x20, to go 7
[ 197.860000] at91_i2c f0014000.i2c: wrote 0x30, to go 6
[ 197.860000] at91_i2c f0014000.i2c: received nack
[ 197.880000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=8
[ 197.880000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.880000] at91_i2c f0014000.i2c: transfer: write 8 bytes.
[ 197.880000] at91_i2c f0014000.i2c: wrote 0x20, to go 7
[ 197.880000] at91_i2c f0014000.i2c: received nack
[ 197.900000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=8
[ 197.900000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.900000] at91_i2c f0014000.i2c: transfer: write 8 bytes.
[ 197.900000] at91_i2c f0014000.i2c: wrote 0x20, to go 7
[ 197.900000] at91_i2c f0014000.i2c: wrote 0x30, to go 6
[ 197.900000] at91_i2c f0014000.i2c: wrote 0x30, to go 5
[ 197.900000] at91_i2c f0014000.i2c: wrote 0x30, to go 4
[ 197.900000] at91_i2c f0014000.i2c: wrote 0x30, to go 3
[ 197.900000] at91_i2c f0014000.i2c: wrote 0x30, to go 2
[ 197.900000] at91_i2c f0014000.i2c: wrote 0x32, to go 1
[ 197.900000] at91_i2c f0014000.i2c: wrote 0xa, to go 0
[ 197.900000] at91_i2c f0014000.i2c: transfer complete
[ 197.900000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=10
[ 197.900000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.900000] at91_i2c f0014000.i2c: transfer: write 10 bytes.
[ 197.900000] at91_i2c f0014000.i2c: received nack
[ 197.920000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=10
[ 197.920000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.920000] at91_i2c f0014000.i2c: transfer: write 10 bytes.
[ 197.920000] at91_i2c f0014000.i2c: transfer complete
[ 197.920000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=17
[ 197.920000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.920000] at91_i2c f0014000.i2c: transfer: write 17 bytes.
[ 197.920000] at91_i2c f0014000.i2c: received nack
[ 197.940000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=17
[ 197.940000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.940000] at91_i2c f0014000.i2c: transfer: write 17 bytes.
[ 197.940000] at91_i2c f0014000.i2c: transfer complete
[ 197.940000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=17
[ 197.940000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.940000] at91_i2c f0014000.i2c: transfer: write 17 bytes.
[ 197.940000] at91_i2c f0014000.i2c: received nack
[ 197.960000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=17
[ 197.960000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.960000] at91_i2c f0014000.i2c: transfer: write 17 bytes.
[ 197.960000] at91_i2c f0014000.i2c: transfer complete
...
Observations/questions:
- The number of NACKs seen on the bus does not match the number
of "received nack" messages, every double NACK on the bus only
has a single "received nack" message AFAICT.
- The bus driver seems to think that the 20ms ACKs are NACKs.
Could it be that the eeprom is engaging in clock stretching
or something such?
- After a 20ms ACK that the bus driver thinks is a NACK, the last
command is reissued, but that seems to result in the tail being
added to the ongoing command that the bus driver thinks have
already terminated with a NACK. Or something?
- It seems to work better when I write spaces.
Cheers,
Peter
WARNING: multiple messages have this Message-ID (diff)
From: Peter Rosin <peda@lysator.liu.se>
To: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Wolfram Sang <wsa@the-dreams.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Ludovic Desroches <ludovic.desroches@atmel.com>,
Cyrille Pitchen <cyrille.pitchen@atmel.com>
Subject: Re: Regression: at24 eeprom writing
Date: Tue, 6 Oct 2015 18:41:16 +0200 [thread overview]
Message-ID: <5613F9AC.3090609@lysator.liu.se> (raw)
In-Reply-To: <CAH9NwWdv=JGGoy4JaGf77v=Z70Ms1ieeKGXNcW2weFaR2wy9+g@mail.gmail.com>
On 2015-10-05 08:16, Christian Gmeiner wrote:
> Hi Peter.
>
> Sorry for the late answer - I am currently on my way to Dublin. Maybe
> it helps if you enable
> I2C_DEBUG_CORE and I2C_DEBUG_BUS. In theory you should see a little
> bit better what
> happens on the bus.
Good suggestion. I did a new run (vanilla 4.2), and this is what I saw on
the bus this time:
[0.00000] S W50 0x00 "product = 1-776-" P
[0.00184] S W50 NACK P
[0.00195] S W50 NACK P
[0.02027] S W50 0x10 ACK...
[0.04035] ...ACK 0x10 "3.0\n" P
[0.04100] S W50 NACK P
[0.04111] S W50 NACK P
[0.06032] S W50 "serial = 380" P
[0.06174] S W50 NACK P
[0.06185] S W50 NACK P
[0.08032] S W50 0x20 ACK...
[0.10034] ...ACK 0x20 "000002\n" P
[0.10127] S W50 NACK P
[0.10138] S W50 NACK P
[0.12039] S W50 0x27 " " P
[0.12155] S W50 NACK P
[0.12166] S W50 NACK P
[0.14040] S W50 0x30 " " P
[0.14219] S W50 NACK P
[0.14230] S W50 NACK P
[0.16042] S W50 0x40 " " P
...
And this is the corresponding part of the log from the same run
(offset ~197.79 s):
[ 197.790000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=17
[ 197.790000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.790000] at91_i2c f0014000.i2c: transfer: write 17 bytes.
[ 197.800000] at91_i2c f0014000.i2c: transfer complete
[ 197.800000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=5
[ 197.800000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.800000] at91_i2c f0014000.i2c: transfer: write 5 bytes.
[ 197.800000] at91_i2c f0014000.i2c: wrote 0x10, to go 4
[ 197.800000] at91_i2c f0014000.i2c: wrote 0x33, to go 3
[ 197.800000] at91_i2c f0014000.i2c: received nack
[ 197.820000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=5
[ 197.820000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.820000] at91_i2c f0014000.i2c: transfer: write 5 bytes.
[ 197.820000] at91_i2c f0014000.i2c: wrote 0x10, to go 4
[ 197.820000] at91_i2c f0014000.i2c: received nack
[ 197.840000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=5
[ 197.840000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.840000] at91_i2c f0014000.i2c: transfer: write 5 bytes.
[ 197.840000] at91_i2c f0014000.i2c: wrote 0x10, to go 4
[ 197.840000] at91_i2c f0014000.i2c: wrote 0x33, to go 3
[ 197.840000] at91_i2c f0014000.i2c: wrote 0x2e, to go 2
[ 197.840000] at91_i2c f0014000.i2c: wrote 0x30, to go 1
[ 197.840000] at91_i2c f0014000.i2c: wrote 0xa, to go 0
[ 197.840000] at91_i2c f0014000.i2c: transfer complete
[ 197.840000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=13
[ 197.840000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.840000] at91_i2c f0014000.i2c: transfer: write 13 bytes.
[ 197.840000] at91_i2c f0014000.i2c: received nack
[ 197.860000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=13
[ 197.860000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.860000] at91_i2c f0014000.i2c: transfer: write 13 bytes.
[ 197.860000] at91_i2c f0014000.i2c: transfer complete
[ 197.860000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=8
[ 197.860000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.860000] at91_i2c f0014000.i2c: transfer: write 8 bytes.
[ 197.860000] at91_i2c f0014000.i2c: wrote 0x20, to go 7
[ 197.860000] at91_i2c f0014000.i2c: wrote 0x30, to go 6
[ 197.860000] at91_i2c f0014000.i2c: received nack
[ 197.880000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=8
[ 197.880000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.880000] at91_i2c f0014000.i2c: transfer: write 8 bytes.
[ 197.880000] at91_i2c f0014000.i2c: wrote 0x20, to go 7
[ 197.880000] at91_i2c f0014000.i2c: received nack
[ 197.900000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=8
[ 197.900000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.900000] at91_i2c f0014000.i2c: transfer: write 8 bytes.
[ 197.900000] at91_i2c f0014000.i2c: wrote 0x20, to go 7
[ 197.900000] at91_i2c f0014000.i2c: wrote 0x30, to go 6
[ 197.900000] at91_i2c f0014000.i2c: wrote 0x30, to go 5
[ 197.900000] at91_i2c f0014000.i2c: wrote 0x30, to go 4
[ 197.900000] at91_i2c f0014000.i2c: wrote 0x30, to go 3
[ 197.900000] at91_i2c f0014000.i2c: wrote 0x30, to go 2
[ 197.900000] at91_i2c f0014000.i2c: wrote 0x32, to go 1
[ 197.900000] at91_i2c f0014000.i2c: wrote 0xa, to go 0
[ 197.900000] at91_i2c f0014000.i2c: transfer complete
[ 197.900000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=10
[ 197.900000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.900000] at91_i2c f0014000.i2c: transfer: write 10 bytes.
[ 197.900000] at91_i2c f0014000.i2c: received nack
[ 197.920000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=10
[ 197.920000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.920000] at91_i2c f0014000.i2c: transfer: write 10 bytes.
[ 197.920000] at91_i2c f0014000.i2c: transfer complete
[ 197.920000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=17
[ 197.920000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.920000] at91_i2c f0014000.i2c: transfer: write 17 bytes.
[ 197.920000] at91_i2c f0014000.i2c: received nack
[ 197.940000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=17
[ 197.940000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.940000] at91_i2c f0014000.i2c: transfer: write 17 bytes.
[ 197.940000] at91_i2c f0014000.i2c: transfer complete
[ 197.940000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=17
[ 197.940000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.940000] at91_i2c f0014000.i2c: transfer: write 17 bytes.
[ 197.940000] at91_i2c f0014000.i2c: received nack
[ 197.960000] i2c i2c-0: master_xfer[0] W, addr=0x50, len=17
[ 197.960000] i2c i2c-0: at91_xfer: processing 1 messages:
[ 197.960000] at91_i2c f0014000.i2c: transfer: write 17 bytes.
[ 197.960000] at91_i2c f0014000.i2c: transfer complete
...
Observations/questions:
- The number of NACKs seen on the bus does not match the number
of "received nack" messages, every double NACK on the bus only
has a single "received nack" message AFAICT.
- The bus driver seems to think that the 20ms ACKs are NACKs.
Could it be that the eeprom is engaging in clock stretching
or something such?
- After a 20ms ACK that the bus driver thinks is a NACK, the last
command is reissued, but that seems to result in the tail being
added to the ongoing command that the bus driver thinks have
already terminated with a NACK. Or something?
- It seems to work better when I write spaces.
Cheers,
Peter
next prev parent reply other threads:[~2015-10-06 16:41 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-02 23:05 Regression: at24 eeprom writing Peter Rosin
2015-10-02 23:05 ` Peter Rosin
2015-10-04 19:50 ` Peter Rosin
2015-10-04 19:50 ` Peter Rosin
2015-10-05 6:16 ` Christian Gmeiner
2015-10-05 6:16 ` Christian Gmeiner
2015-10-06 16:41 ` Peter Rosin [this message]
2015-10-06 16:41 ` Peter Rosin
2015-10-05 8:45 ` Peter Rosin
2015-10-05 8:45 ` Peter Rosin
2015-10-05 8:59 ` kbuild test robot
2015-10-05 8:59 ` kbuild test robot
2015-10-05 15:00 ` Ludovic Desroches
2015-10-05 15:00 ` Ludovic Desroches
2015-10-05 15:09 ` Peter Rosin
2015-10-05 15:09 ` Peter Rosin
2015-10-12 15:13 ` Peter Rosin
2015-10-12 15:13 ` Peter Rosin
2015-10-12 16:13 ` Cyrille Pitchen
2015-10-12 16:13 ` Cyrille Pitchen
2015-10-13 10:38 ` Peter Rosin
2015-10-13 10:38 ` Peter Rosin
2015-10-13 12:57 ` Nicolas Ferre
2015-10-13 12:57 ` Nicolas Ferre
2015-10-13 14:35 ` Peter Rosin
2015-10-13 14:35 ` Peter Rosin
2015-10-13 13:26 ` ludovic.desroches at atmel.com
2015-10-13 13:26 ` ludovic.desroches
2015-10-05 15:28 ` Cyrille Pitchen
2015-10-05 15:28 ` Cyrille Pitchen
2015-10-05 15:54 ` Peter Rosin
2015-10-05 15:54 ` Peter Rosin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5613F9AC.3090609@lysator.liu.se \
--to=peda@lysator.liu.se \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.