-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Arduino stuck at PCD_Init() with 3.3V power supply #426
Comments
Can not reproduce your reported bug. |
I tried with the original v1.4.1 lib once again with dis- and reconnecting the Arduino from the PC. But that did not change anything. Then I switched back to the modified MFRC522.cpp and it worked instantaneously (regardless if I try immediately after flashing or following a dis- and reconnect). Could it be a nasty behaviour caused by the way the Arduinos are automatically enabling pull-up resistors on pins when switching modes depending on the states the pins are in before switching, like explained in https://www.arduino.cc/en/Tutorial/DigitalPins? Maybe the initial states of the reset pins differ on our setups? Excerpt:
|
I did not intend to close the case, did this by mistake. Please keep looking into it. |
Now tested with two different chinese arduino boards: genuine like version and smd version with ch340. I don't think it's a pullup resistor problem, because the external state should not affect whether there is a pullup or not. You can try a delay between: // First set the resetPowerDownPin as digital input, to check the MFRC522 power down mode.
pinMode(_resetPowerDownPin, INPUT);
if (digitalRead(_resetPowerDownPin) == LOW) { // The MFRC522 chip is in power down mode. Or add some debug messages. |
I tried several delays between pinMode switching, this did not change a thing. So I grabbed my oszilloscope and checked the differences of the RST pin signal between the two lib versions. By doing so I realized that in OUTPUT mode the voltage level of the PIN9/RST connection is at around 4.8V (the HIGH of the Arduino). After switching it to INPUT mode, the voltage level drops to 3.3V (the HIGH of the RC522 board). That in turn made me realize that with the new lib version PIN9 stays in INPUT mode in case the RC522 board is not in power down mode (i.e. it's RST pin is HIGH) while it will be left at OUTPUT mode if the board was powered down. So I added an else branch to the if which sets PIN9 back to OUTPUT mode. Unfortunately that broke the communication with the board completely (probably because the initial level is LOW which sends the RC522 to sleep).
So I added a digitalWrite(_resetPowerDownPin, HIGH) to the pinMode(_resetPowerDownPin, OUTPUT) of the else branch which not only brought back the communication with the board but made the library work. But basically that means that the else branch is doing almost the same as the if branch (except for the delay and skipping the soft reset). However one might assume that because the RST pin of the RC522 was in HIGH state before (at 3.3V) putting the PIN9 to HIGH (at 4.8V) should not trigger a reset. In that case the problem with my setup is the "left over" INPUT mode of PIN9. But if setting it to HIGH after putting it to OUTPUT mode did trigger a reset on the RC522, the issue might just be solved by that reset which does not proof anything. // If a valid pin number has been set, pull device out of power down / reset state.
if (_resetPowerDownPin != UNUSED_PIN) {
// First set the resetPowerDownPin as digital input, to check the MFRC522 power down mode.
pinMode(_resetPowerDownPin, INPUT);
if (digitalRead(_resetPowerDownPin) == LOW) { // The MFRC522 chip is in power down mode.
pinMode(_resetPowerDownPin, OUTPUT); // Now set the resetPowerDownPin as digital output.
digitalWrite(_resetPowerDownPin, HIGH); // Exit power down mode. This triggers a hard reset.
// Section 8.8.2 in the datasheet says the oscillator start-up time is the start up time of the crystal + 37,74μs. Let us be generous: 50ms.
delay(50);
hardReset = true;
}
else {
pinMode(_resetPowerDownPin, OUTPUT); // Now set the resetPowerDownPin as digital output.
digitalWrite(_resetPowerDownPin, HIGH); // Exit power down mode. This triggers a hard reset.
}
}
However I am on a business trip the next two days so I will not be able to make further tests. But maybe you have some additional thoughts in the meantime. Thanks for your support so far. |
@SheldorAFK Can you do two more tries?: 1. Use only software based reset
This disables the hardware pin based reset. Only the software based is done. 2. Use 5V power instead of 3.3V
My short analysisMy mfrc board is "active" if power is connected. So the rst pin should have 3.3V or 5V (depending on powering). According to this, the library does not perform a hardware reset or power up by reset pin. I don't need the hardware based reset and it also works with the software based reset. Data sheetAfter reading the datasheet I improved the reset code a bit. See 3592862 . |
I ran the sketch with a disconnected RST pin as well as with the RST pin set to UNDEFINED (0xFF). With that configuration the DumpInfo.ino sketch partially worked. It did return the RC522 board version number at startup. And if an RFID token was placed on the reader, it's UID could be read. However reading the data blocks of the token still failed. So I checked the signal levels again with the Oszilloscope. When the RF522 was powered on the state of the RST PIN was HIGH (3.3V). PIN 9 of the Arduino was at LOW level at power on. Thus with the pre 1.4.0 PCD_Init() version, the if condition was met and the PIN9 of the Arduino was set to HIGH (5V). Even though the RST pin of the RF522 was already at HIGH (3.3V), I could verify that by setting the pin to the 5V HIGH of the Arduino, my RF522 board performed a hard reset. And after the hard reset it worked properly. That on the other hand made me wonder if driving the 3.3V signals with 5V levels is really a good idea. I ordered a set of active level shifters which arrived today. With the level shifters placed between the Arduino and the RF522 board the sketch still did not work. The behaviour was similar to the tests with the disconnected RST pin without the shifters. I checked the MOSI and MISO signals with the Oszilloscope and could see that the raising edges were closer to sine waves than to square signals. In addition the RST signal was jittering heavily. So I added an external 3.3V (actually 3.6V) power supply to the RF522 board and the level shifters. Before I was using the 3.3V output of the Arduino. With the additional power supply in place the signal edges improved significantly and the RST jitter was gone. Reading tokens with the DumpInfo.ino sketch worked instantaneously. This means my issues were related to driving the 3.3V board with 5V levels. Unfortunately those issues did not have any effect if the board was hard reset during PCD_Init(). I have to admit that I fell to the many direct wiring proposals available at various web sites without questioning their validity. I am sorry for all the hassle caused by my stupidity. To make a long story short, the current version of the library is correct. It only breaks badly wired circuits like in my case. Once again sorry for all the confusion and thank you very much for your quick and profound support. |
Hi, Regards. |
Step 1: Describe your environment
Step 2: Describe the problem
Starting with library version 1.4.0 the method PICC_ReadCardSerial() is not returning any UID data. I tested with the example sketch DumpInfo.ino as well as with the following minimalistic read loop:
If using any of the 1.3.x library versions (including 1.3.6) both sketches work fine. But when using the libraries 1.4.0 and 1.4.1 the PICC_ReadCardSerial() method fails (returns a status of 0). The only significant change I found in the MFRC522.cpp module was the changed handling of the reset pin initialization inside of the method PCD_Init(). I reverted the associated code section of the v1.4.1 module to the one used in v1.3.6 and after that the sketches worked with the modified v1.4.1 version as well.
This means that at least for my board combination the change introduced in v1.4.0 ("Fixed hang PCD_Init() on non-arduino boards @heziegl" according to the change log) broke the library. The example firmware_check.ino sketch worked flawlessly with any library version and returned the following output:
Affected file(s) or example(s):
Steps to reproduce:
Observed Results:
Expected Results:
Relevant Code:
Original code section of PCD_Init() in version 1.4.0 and 1.4.1 of MFRC522.cpp causing the read issues
Reverted code section of PCD_Init() like used in version 1.3.6 of MFRC522.cpp fixing the read issues
Even though the new code section seems to implement the proper approach because the pinMode reflects the read and write actions accordingly, but for my combination of boards it definately does not work. Maybe switching the pinMode from input to output happens too quickly or is not supported at all by my UNO clone.
It would be great if you could check with other board combinations. Maybe boards from other vendors suffer from the same issue. I am not sure if it makes sense to revert the change in the library because I assume it had been incorporated for a good reason. But it would at least be worth noting for others which might suffer from the same problem.
The text was updated successfully, but these errors were encountered: