I2C Clock stretching on PN532 leads to bus error (?)

Busy with debugging issues with a PN532 tag reader. Most of the time things are ok, but sometimes when reading a tag, the I2C bus get's stuck. The ESP will automatically reset the PN532 and everything will be just fine after that. But what's going on with the bus error and why?.

I already figured out that SDA remains low for some reason (and stays until the PN532 is reset)

So I started debugging with the logic analyzer and there may be some issue due to clock stretching?
I'm just guessing here... It could be that the PN532 is not ready and stretches the clock?

This is what happens with a normal read from the PN532. There's a gap between start and first byte written. It's approx. 100 uSec and things run ok.

But when the bus error appears, there's a gap of approx. 250 uSec and the first byte has an issue. It should be a zero byte but I guess somethings happening within the I2C libs...

Could my theory make any sense? If it is clock stretching, does the I2C library support what's going on here...

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[pasko-zh]

Maybe it is somehow related to this issue

I found this comment in the I2C core library:

while (SCL_READ() == 0 && (i++) < TWI_CLOCK_STRETCH);// Clock stretching (up to 100us)

So this could explain the bus errors.

So I decided to change the library settings to allow for 1 mSec:

#if F_CPU == FCPU80
#define TWI_CLOCK_STRETCH 8000 // default was 800
#else
#define TWI_CLOCK_STRETCH 16000 // default was 1600
#endif

And after more than 10 hours of testing, bus errors are gone...

I've checked the official I2C protocol datasheets but could not find anything on maximum allowed clock stretching time window.

But the NXP PN532 datasheet states that the unit can take up to 2 mSec clock stretching with 500 uSec typical.

So if the guys who invented the I2C protocol use such a delay in their own firmware, it seems that they consider this a valid delay.

Where's the 100 uSec stretch delay limit in the current library based on?

If developers agree that this is an issue with the current ESP core, I would like to propose a new function call to change this timeout, instead of changing a hardcoded value. Something like:

Wire.setClockStretchLimit(uint32_t);

[Links2004]

fell free to create a Pull Request.

keep in mind that using a variable here:
https://github.com/esp8266/Arduino/blob/master/cores/esp8266/core_esp8266_si2c.c#L101
may change the timings a little (may do some measures to verify the timings).
may give the setClockStretchLimit "us" as parameter and do the needed cpu cycle calculation intern by this its easier to use.

Made changes to the I2C library. Strange observation though, while checking timings:

If I time this line of code with TWI_CLOCK_STRETCH set to 800 (default value):

while (SCL_READ() == 1 && (i++) < TWI_CLOCK_STRETCH);

it gives me a 230 uSeconds delay. The comments in the code mention 100 uSeconds. (?)

So to keep default behavior the same as the unpatched version, I should initialize the new internal variable with 230 uSeconds

Tested with the PN532 device. With default settings, still issues (as expected) and when I use

Wire.setClockStretchLimit(2000);

Issues are solved.

Pull request has been made.

[supersjimmie]

I added Wire.SetClockStretchLimit(2000) without success.
The PN532 cannot be found. Very rare it came up after numberous retries (>10) but mostly never.
When I enable DEBUG:

write:  2
wait for ack at : 272
Time out when waiting for ACK
Didn't find PN53x board

And only when it sometimes suddenly works:

write:  2
wait for ack at : 272
ready at : 274
read:   3 32 1 6 7
init done
Found chip PN532
Firmware ver. 1.6
write:  32 5 FF 1 FF
wait for ack at : 284
ready at : 286
read:   33
SAMConfig
write:  14 1 14 1
wait for ack at : 295
ready at : 297
read:   15
Waiting for an ISO14443A card
write:  4A 1 0
wait for ack at : 306
ready at : 308
read:   4B 1 1 0 4 8 4 75 AB A0 43
ATQA: 0x 4SAK: 0x 8

And if I then just reset the ESP, it stops working again. :(
So without any changes, it mostly does not work, but sometimes it does.

[pasko-zh]

Just to verify: Your hardware setup is correct? Pull-ups etc.?

I guess you are using adafruits library, right? On their site it says: "ESP8266 SPI only, I2C clock stretching not supported"... and it has an X in the "doesn't work"

[supersjimmie]

I tried either with and without pullups. Yes I know the source says doesn't work, but have you read the comments here above? It doesn't (didn't) work because of the clock stretching problem and that should have been fixed by the addition of the 'Wire.setClockStretchLimit'.
See above comments.

mvdbro says:

Tested with the PN532 device. With default settings, still issues (as expected) and when I use
Wire.setClockStretchLimit(2000);
Issues are solved.

Wiring is correct otherwise it would not work at all.
If it gets past the begin(), then all keeps working until I simply reset and then it doesn't pick it up anymore..

(EDIT: With both the adafruit and the seed-studio libraries)

What I noticed is that it helps to remove power from the PN532 if it doesn't work. Most times it starts working if I simply remove it's power and reconnect it...

[pasko-zh]

Yes, I read the comments above.

The behaviour your describing seems to me like you have a floating pin somewhere. It reminds me of people writing emails to me that my esp8266 Assembly i2c library does not always work. And it turned out that for instance they forgot to connect the (not) Reset Pin of an MCP 23017, causing it to work sometimes, sometimes not, or work after a disconnect for a couple of times ...

Do you have a scope at hand to check the i2c communication?

[supersjimmie]

Sorry, I don't have a scope.
I can also confim that in the exact same setup (wires, pins, breadboard, etc) it works fine on an arduino nano. I had only wires attached to the 4 connections for i2c, VCC, GND, SDA, SCL. Wires are only 10cm long. The PN532 is setup for i2c with onboard dipswitches, so it does not listen to any of the (unconnected) SPI pins.

[pasko-zh]

...and I don't have an PN532 at hand to check with my scope :-/
When you connect another I2C device instead of a PN532, does I2C then work? Just to find out, whether the issue is PN532-only or if it is perhaps a wire library issue.
btw, which Arduino IDE and esp8266 core version are you using?

[supersjimmie]

IDE 1.6.9 and the current stable esp core version (2.2.0 through boards manager).
I'm almost constantly using a couple of ds18b20 1-Wire temperature sensors for months now without any issue ever, but I think that's too different from how it works with the PN532?

Currently I don't have any I2C device available.

Today the Arduino IDE notified me about an update for the Wire library, but that's the Arduino Wire library. EDIT: wasn't Wire but OneWire update.

Since I wanted to continue work, I decided to solder the SPI pins to the PN532 and that works flawless. But because of the better flexibility and less wires for I2C, I would love to go "back" from SPI to I2C.

[supersjimmie]

Would it be of any use to simply test I2C between 2 ESP's like this?
https://www.arduino.cc/en/Tutorial/MasterWriter

EDIT: Which will not work because the ESP core doesn't support I1C slave mode afaik.
So after hours of struggling, I now need to make an Arduino slave. Then use:
https://www.arduino.cc/en/Tutorial/MasterReader

[supersjimmie]

Now I have now a working i2c master-slave between an esp8266 and an arduino (pro mini 3.3v).
That proves that a basic implementation of an I2C master works with my esp8266, ide, core, libraries, wiring, etcetera.

As discussed above, there were issues between an esp and a PN532, but from what I can understand those should have been solved with the Wire.setClockStretchLimit(2000)?

EDIT: I have reconnected with I2C now.
What I noticed is that the begin() fails very fast if nothing is connected, while there is a delay (1 sec or so) if the PN532 is connected but does not work. So it does see something?