I2C SCL frequency 10% less than it should be at 400kHz

[mvrhov]

Well even with the latest patch I2C still doesn't work with PN532 boards. e.g ones like this

[MartyMacGyver]

Well even with the latest patch I2C still doesn't work with PN532 boards. e.g ones like this

It doesn't work at all or has glitches? Does that device work with any other Arduino-type device you have?

[mvrhov]

It can find it on the BUS (if you do a scan), send and receive a few bytes then gets stuck.
Yes, the board works on Arduion uno.
I've added a lot of debug printf's into the code and it fails at various times. If it fails one then next time you try it will fail earlier. You have to do full reset and then it will fail at the same place as the first time.

[MartyMacGyver]

I don't have one of these boards (yet)... it'd take a few days to get one here.

Is it specifically the HiLetgo one you linked to?
Version 3 or something earlier?
What GPIO pins are you wiring to what pins on the board?
Where's your code?
Are you using the latest Arduino-ESP32 as well as latest Arduino?

Edit: The exact device in the link you gave matches the layout of what Elechouse (and evidently HiLetgo) sell.

http://www.elechouse.com/elechouse/inde ... ts_id=2242

Now what's interesting is Elechouse has the following note about copies of their product:

http://www.elechouse.com/elechouse/imag ... t_copy.pdf

In addition, the manual for the v3 module talking about level shifters - that specifically mentions the I2C references 5V:

http://www.elechouse.com/elechouse/imag ... ual_V3.pdf

But the schematic suggests it's 3.3V referenced:

http://www.elechouse.com/elechouse/imag ... rowing.pdf

So my question for you is, what kind of Arduino are you using, and are you level shifting with that or with the ESP32? Or does your particular device require it at all? If it works with a 5V Arduino with no extra hardware or level shifting, perhaps the 3.3V ESP32 doesn't work as well with it... or the design is different than the one above.

Or it's an I2C problem - knowing what pins you used and what kind of code you ran will help, since unless someone has the same device you it's hard to debug this.

[mvrhov]

It's the board listed there. It's connected to the 2.54pin header where only i2c + power is exposed. the switch is set to i2c!
I did a fresh git update. before trying a few days ago. And the patch mentioned above is present.
Tried it again with todays 31.3 commit ba1efb9897

This is the code.

Code: Select all

/**************************************************************************/
/*! 
    This example will attempt to connect to an ISO14443A
    card or tag and retrieve some basic information about it
    that can be used to determine what type of card it is.   
   
    Note that you need the baud rate to be 115200 because we need to print
    out the data and read from the card at the same time!

    To enable debug message, define DEBUG in PN532/PN532_debug.h
    
*/
/**************************************************************************/

#include <Wire.h>
#include <PN532_I2C.h>
#include "PN532.h"

PN532_I2C pn532i2c(Wire);
PN532 nfc(pn532i2c);

void setup(void) {
  Serial.begin(115200);
  delay(10);
  Serial.print("initializing i2c..");
  Wire.begin(21,22,400000);
  Serial.print("DONE\n");

  nfc.begin();

  uint32_t versiondata = nfc.getFirmwareVersion();
  if (! versiondata) {
    Serial.print("Didn't find PN53x board");
    while (1); // halt
  }
  
  // Got ok data, print it out!
  Serial.print("Found chip PN5"); Serial.println((versiondata>>24) & 0xFF, HEX); 
  Serial.print("Firmware ver. "); Serial.print((versiondata>>16) & 0xFF, DEC); 
  Serial.print('.'); Serial.println((versiondata>>8) & 0xFF, DEC);
  
  // Set the max number of retry attempts to read from a card
  // This prevents us from waiting forever for a card, which is
  // the default behaviour of the PN532.
  nfc.setPassiveActivationRetries(0xFF);
  
  // configure board to read RFID tags
  nfc.SAMConfig();
    
  Serial.println("Waiting for an ISO14443A card");
}

void loop(void) {
  boolean success;
  uint8_t uid[] = { 0, 0, 0, 0, 0, 0, 0 };  // Buffer to store the returned UID
  uint8_t uidLength;                        // Length of the UID (4 or 7 bytes depending on ISO14443A card type)
  
  // Wait for an ISO14443A type cards (Mifare, etc.).  When one is found
  // 'uid' will be populated with the UID, and uidLength will indicate
  // if the uid is 4 bytes (Mifare Classic) or 7 bytes (Mifare Ultralight)
  success = nfc.readPassiveTargetID(PN532_MIFARE_ISO14443A, &uid[0], &uidLength);
  
  if (success) {
    Serial.println("Found a card!");
    Serial.print("UID Length: ");Serial.print(uidLength, DEC);Serial.println(" bytes");
    Serial.print("UID Value: ");
    for (uint8_t i=0; i < uidLength; i++) 
    {
      Serial.print(" 0x");Serial.print(uid[i], HEX); 
    }
    Serial.println("");
    
    // wait until the card is taken away
    while (nfc.readPassiveTargetID(PN532_MIFARE_ISO14443A, &uid[0], &uidLength)) {}
  }
  else
  {
    // PN532 probably timed out waiting for a card
    Serial.println("Timed out waiting for a card");
  }
}

One type of output. I added a lot of debug messages to the original library.

Code: Select all

initializing i2c..DONE
write:  2
wait for ack at : 54
waiting for start (ACK):  0ACK not ready
waiting for start (ACK):  0ACK not ready
waiting for start (ACK):  0ACK not ready
waiting for start (ACK):  0ACK not ready
waiting for start (ACK):  0ACK not ready
waiting for start (ACK):  0ACK not ready
waiting for start (ACK):  0ACK not ready
waiting for start (ACK):  0ACK not ready
waiting for start (ACK):  0ACK not ready
waiting for start (ACK):  0ACK not ready
waiting for start (ACK):  0ACK not ready
Time out when waiting for ACK
Didn't find PN53x board

The 2nd one if you do reset.

Code: Select all

initializing i2c..DONE
write:  2
wait for ack at : 49
ACK not ready
waiting for start (ACK):  1ready at : 50
Done reading
ACK OK
read (RSP):
and after a long time!!
Respponse fail -99Didn't find PN53x board

The library is from here with line 17 commented out.

[MartyMacGyver]

I've got no idea why this would be failing, but as I'm curious about the tech in general anyway I ordered what appears to be the same one from Amazon. I'll have it on Monday and can delve into it then.

[mvrhov]

I've also tried it with a borrowed arduino Due and it also works.

[Hans Dorn]

A little update from my side:

I added an oled display and an arduino to my I2C setup to generate some traffic.
While testing some changes to make things faster I ran into issues with unreliable communication.
Errors will pop up several times a day, causing my reboot logic to trigger.

I just undid the last change I posted (faster i2c_set_cmd) and will see how the reliability of the slow version is.

I also ran across a bug that causes i2c transmissions to fail when there's more than 32 bytes in the Wire library's txBuffer.
Will try to tackle this when I'm done with reliability testing...


Cheers
Hans

[MartyMacGyver]

I've also tried it with a borrowed arduino Due and it also works.

That Seeed-Studio repo you're based on is rather ancient... I just tried the Adafruit PN532 library (https://github.com/adafruit/Adafruit-PN532) and with a few small modifications examples/iso14443a_uid worked fine on both Particle and ESP32.

The few simple steps:

Add a define check for "ESP32" in Adafruit_PN532.cpp:

#include <Wire.h>
#if defined(__AVR__) || defined(__i386__) || defined(ARDUINO_ARCH_SAMD) || defined(ESP8266) || defined(ESP32) || defined(ARDUINO_ARCH_STM32)
#define WIRE Wire
...

Use the default I2C pins
IO21 = SDA, IO22 = SCL

In the example sketch:

Specify an IRQ pin (and hook up the IRQ line from the board). I used IO16. I specified IO17 because better safe value than sorry, even though I didn't wire that pin to anything):
#define PN532_IRQ (16)
#define PN532_RESET (17) // Not connected by default on the NFC Shield

Comment out the SPI initializer around line 46 and uncomment the I2C one which looks like this:
Adafruit_PN532 nfc(PN532_IRQ, PN532_RESET);

Finally, I changed the halt loop slightly (doesn't matter except for OTA flashed boards like the Particle):
while (1) {delay(1000);} // halt

That's it... this board was remarkably painless to hook up versus everything else I've been working on lately.

[MartyMacGyver]

I added an oled display and an arduino to my I2C setup to generate some traffic.
While testing some changes to make things faster I ran into issues with unreliable communication.
Errors will pop up several times a day, causing my reboot logic to trigger.

Please update to the latest Arduino-ESP32 - a lot of changes went in today... this may improve things for you. Let us know how it goes!