Hello I have got the same issue but adding pull-up resistors on A4 and A5 (I have used 1kohm, also I have tried with 3.3 kohm) as per Grumpy_Mike solution has not resolved it. The only difference in my case I am not using I2C to add sensor, but a PN532 nfc breakout board (3.3 v VCC). It works on the Uno R3, it doesn't see the PN532 on the Uno R4. I am using the same computer to compile and upload, the same code and the same breakout.
Gilshultz, thank you.
I have already tried the same configuration with 3.3k resistors, results are the same.
Switches on the PN532 board have been double/triple checked and trials repeated at least three times, both with R4 and R3.
This is the test code I have been using
/*
* librerie NDEF
* https://github.com/don/NDEF
* e richiede anche
* https://github.com/Seeed-Studio/PN532
*
* https://www.dummies.com/consumer-electronics/nfc-data-exchange-format-ndef/
*/
#include <Wire.h>
#include <PN532_I2C.h>
#include <PN532.h>
#include <NfcAdapter.h>
PN532_I2C pn532_i2c(Wire);
NfcAdapter nfc = NfcAdapter(pn532_i2c);
//#include <SPI.h>
//#include <PN532_SPI.h>
//PN532_SPI intf(SPI, 10);
//PN532 nfc = PN532(intf); use ndef library instead
//NfcAdapter nfc = NfcAdapter(intf);
//display
//#include <LiquidCrystal_I2C.h>
//#define I2C_ADDR 0x27
//#define BACKLIGHT_PIN 3
//#define En_pin 2
//#define Rw_pin 1
//#define Rs_pin 0
//#define D4_pin 4
//#define D5_pin 5
//#define D6_pin 6
//#define D7_pin 7
//LiquidCrystal_I2C lcd(I2C_ADDR,En_pin,Rw_pin,Rs_pin,D4_pin,D5_pin,D6_pin,D7_pin);
void setup(void) {
Serial.begin(9600);
Serial.println("NDEF Reader");
nfc.begin();
//lcd.begin(16,2);
//lcd.setBacklightPin(BACKLIGHT_PIN,POSITIVE);
//lcd.setBacklight(HIGH);
//lcd.home();
//lcd.setCursor(0,0);
//lcd.print("NFC Reader");
}
void loop(void) {
if (nfc.tagPresent()) {
NfcTag tag = nfc.read();
String id = tag.getUidString();
if (tag.hasNdefMessage()) {
NdefMessage message = tag.getNdefMessage();
Serial.print("\nThis NFC Tag contains an NDEF Message with ");
Serial.print(message.getRecordCount());
Serial.println(" NDEF Record");
// cycle through the records, printing some info from each
int recordCount = message.getRecordCount();
for (int i = 0; i < recordCount; i++) {
Serial.print("\nNDEF Record ");Serial.println(i+1);
NdefRecord record = message.getRecord(i);
Serial.print(" TNF: ");Serial.println(record.getTnf());
Serial.print(" Type: ");Serial.println(record.getType()); // will be "" for TNF_EMPTY
// The TNF and Type should be used to determine how your application processes the payload
// There's no generic processing for the payload, it's returned as a byte[]
int payloadLength = record.getPayloadLength();
byte payload[payloadLength];
record.getPayload(payload);
// Print the Hex and Printable Characters
Serial.print(" Payload (HEX): ");
PrintHexChar(payload, payloadLength);
// Force the data into a String (might work depending on the content)
// Real code should use smarter processing
String payloadAsString = "";
for (int c = 3; c < payloadLength; c++) { //salto en0
payloadAsString += (char)payload[c];
}
Serial.print(" Payload (as String): ");
Serial.println(payloadAsString);
//lcd.setCursor(0,1);
//lcd.print(payloadAsString);
// id is probably blank and will return ""
String uid = record.getId();
if (uid != "") {
Serial.print(" ID: ");Serial.println(uid);
}
}
}
} else {
Serial.println("NOTAG");
//lcd.setCursor(0,1);
//lcd.print(" ");
delay(1000);
}
}
@ragganissu
The board you have operates on 5V and has pull-ups with level translators.
Connect Vcc to 5V and remove those external 1K pull-ups, then it will work with the R4 and R3
Thank you Jim, I have just tried your suggestion, no pull-ups and 5v power. Unfortunately it did not solve the issue and I got the same old error: "Didn't find PN53x board". For the records I have also tried at firs the 3.3 v solution without pullups, that was my first try.
Also, before adding pull-ups, I have inspected the PN532 board and I have tried to follow the traces from the scl and sda pin to the ic. Seems to me that there are no pull-ups at all on the board, at least for the sda trace I am quite sure it goes straight into the ic. We know that on R4 pull-ups on the I2C lines are not mounted by design. I will try to take another look at the PN532 board and report back
I found this schematic. It seem to match the board you show in post #5
It shows level translators and pull-ups but only on the IC side So I was wrong you do need external pull-ups but to 5V NOT 3.3V. 10K or 4.7K should be fine
Thanks a lot! The board in the image in post 5 is indeed the one I am using. I will have a chance to try this new solution in the next two-three days, I will let you know
Hello, I have made some test with jim-p suggestion, from his schematics investigations. I have swapped resistor from post #5 (1k) with 10k and 3.3 v power (VCC) with 5v. Results have been strange, mostly didn't work as usual, but on pushing reset on the R4, sometimes it recognized the pn352 correctly. So I added another 10k resistor in parallel on each I2C line and got 5k resistance pull-ups (I don't have 4.7 k resistors). This time problems at start-up did't show up, but pn532 still is behaving erraticaly, espacially when compared with R3 Uno functioning results, which are very solid and consistent.
What happens is after some readings, somwhere between four and ten, an error show up and that stops the PN532, the R4 needs to be resetted to start functioning again. I am copying most of the serial communication dumps below. Also, some cards cannot be read (Mifare EV ultralight are read and report no payload, when there is one), and other are triggering the error a lot (Mifare classic can be read in the payload but "shuts down" the PN532 a lot).
I will investigate more and report
15:15:35.670 -> NDEF Reader
15:15:36.238 -> Didn't find PN53x boardNDEF Reader
15:15:51.951 -> Found chip PN532
15:15:51.951 -> Firmware ver. 1.6
15:15:58.629 -> Error. Failed read page 4
15:15:58.793 ->
15:15:58.793 -> This NFC Tag contains an NDEF Message with 1 NDEF Record
15:15:58.793 ->
15:15:58.793 -> NDEF Record 1
15:15:58.793 -> TNF: 0
15:15:58.793 -> Type:
15:15:58.793 -> Payload (HEX):
15:15:58.793 -> Payload (as String):
15:16:13.889 ->
15:16:13.889 -> This NFC Tag contains an NDEF Message with 1 NDEF Record
15:16:13.889 ->
15:16:13.889 -> TNF: 1
15:16:13.889 -> Type: T
15:16:13.889 -> Payload (HEX): 02 65 6E 62 6C 61 73 74 69 63 20 6D 75 64 61 72 74 65 .enblastic mudarte
15:16:14.026 -> Payload (as String): blastic mudarte
15:16:16.601 -> Read failed 4
15:16:16.710 -> Read failed 5
15:16:16.710 ->
15:16:16.710 ->
15:16:16.710 -> Firmware name: "C:\Users\zacca\AppData\Local\Temp\arduino\sketches\0DD4DB598385410837C66D9F4735C5A3/floatToString.ino", compiled on: Aug 1 2024
15:16:16.843 -> Fault on interrupt or bare metal(no OS) environment
15:16:16.843 -> ===== Thread stack information =====
15:16:16.987 -> addr: 20007ca8 data: 20007ccc
15:16:16.987 -> addr: 20007cac data: 00005bd1
15:16:16.987 -> 15:16:16.710 -> Firmware name: "C:\Users\zacca\AppData\Local\Temp\arduino\sketches\0DD4DB598385410837C66D9F4735C5A3/floatToString.ino", compiled on: Aug 1 2024
15:16:16.843 -> Fault on interrupt or bare metal(no OS) environment
15:16:16.843 -> ===== Thread stack information =====
15:16:16.987 -> addr: 20007ca8 data: 20007ccc
15:16:16.987 -> addr: 20007cac data: 00005bd1
15:16:16.987 -> addr: 20007cb0 data: 0000005a
15:16:17.136 -> addr: 20007cb4 data: 53000078
15:16:17.136 -> addr: 20007cb8 data: 00000053
15:16:17.136 -> addr: 20007cbc data: 000059ab
15:16:17.136 -> addr: 20007cc0 data: 20002508
15:16:17.285 -> addr: 20007cc4 data: 00000040
15:16:17.285 -> addr: 20007cc8 data: 20000024
15:16:17.285 -> addr: 20007ccc data: 20007e01
ecc ecc
--
--
15:16:22.927 -> addr: 20007eec data: 00005eb3
15:16:22.927 -> addr: 20007ef0 data: 00013648
15:16:23.043 -> addr: 20007ef4 data: 00009ecf
15:16:23.043 -> addr: 20007ef8 data: 00009ec5
15:16:23.043 -> addr: 20007efc data: 00002599
15:16:23.203 -> ====================================
15:16:23.203 -> =================== Registers information ====================
15:16:23.203 -> R0 : 00000000 R1 : 20008000 R2 : 73007e06 R3 : 00000271
15:16:23.311 -> R12: 00000001 LR : 00005bd1 PC : 0000faee PSR: 81000000
15:16:23.456 -> ==============================================================
15:16:23.456 -> Bus fault is caused by precise data access violation
15:16:23.456 -> The bus fault occurred address is 20008000
15:16:23.602 -> Show more call stack info by run: addr2line -e "C:\Users\zacca\AppData\Local\Temp\arduino\sketches\0DD4DB598385410837C66D9F4735C5A3/floatToString.ino".elf -a -f 0000faee 00005bd0 000059aa 00005df4 000055a2 000053e8 00005484 00005d26 00005cee 00004120 0000c8b8 0000c8f6 00005eb2 00009ece 00009ec4
I think the pull-up issue is resolved but I have no experience with the R4. It has been reported that some libraries that work on the R3 won't work on the R4. I don't know if the lib you are using is one of them.
Thank you jim-p, I think you are right, the pull-up issue has been resolved by your great suggestion and your kind and clever research to get the right schematics. The problem in the topic, that is discrepancies in functionality between R4 and R3 is only partially solved. I think maybe some more equipped board could have better circutry, but I am bound to use budget ones. Also even some more pricey one, like dfrobot pn352 board, have dicontinued the use of level shifter on board. So maybe a complete solution for the issue could be valuable for the community. We'll see
I think the library is not the problem beacause I am getting some right results, otherwise i could never get them, I think. The fact is results are not consistent in this configuration and I am suspecting something is not right from an electric circuit standpoint. The ability to resolve this is beyond my capabilities, I still am open to suggestion. For now, I think I will use a workaround putting a cheap nano clone between the PN532 shield and the R4. It would be nice finding some electrical components that could solve the problem. Maybe a filter or a capacitor... If someone can suggest some analysis techniques to do on the board, I have an oscilloscope to try that (I am still a noob at it, though). I will update if the nano workaround functions right or not
I wouldn't come to that conclusion, although I agree it could still be a hardware issue with the R4. It is quite a different processor from the R3 and I know the I2C interface is different.
Maybe someone has a simple test program for the PN532 that does not use the lib so you can rule that out as a problem
Oh, yes, I have done that! I have used adafruit pn352 library and it works with the R4, so that is another fact that could help us rule out library problems from the list (not totally sure though). My problem with that library is that it doesn't let me get the reading of the payload I write into the cards or the tags. I have tried for many days with four types of tags with no luck. So I changed libraries and got the results I needed. But it only worked on Uno R3 (perfect results every time). R4 have been a different thing. I think shield board producers have been downgrading their board, leaving out component, to optimize costs. I suspect some clever electrical workaround could solve this
Basically the R4 is a completely different board and many people think it was a mistake calling it the Uno R4.
From the R4 product page.
Are all libraries compatible with the UNO R3 also compatible with the UNO R4 Minima?
No, some UNO R3 libraries use instructions of the AVR architecture that are not compatible with the architecture of the UNO R4 Minima, however there are libraries that have already been ported as part of our early adopters program or are based on the Arduino API.
Ok, I have made some more test in that suggested configuration with 5kohms (two 10kohms in parallel) pull-ups instead of 1kohms as in post #5 image.
I have got acceptable results using mifare classic 1k card.
With ultralight it doesn't work, with ultralight ev1 sometimes works.
I am suspecting the sketch doesn't help very much and altough using an UNO R3 or a Nano doesn't give me errors (with the same sketch and libraries and no pull-ups), the solution suggested in post #10, paired with mifare classic 1k cards usage and I2C communication will be my go-to solution this time.
If I will make some improvement in the issue in time, I will update here. Thank you.
