Skip to content
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

Versions >=1.4.0 unstable with Wemos D1 mini #427

Closed
anduck opened this issue Oct 8, 2018 · 12 comments
Closed

Versions >=1.4.0 unstable with Wemos D1 mini #427

anduck opened this issue Oct 8, 2018 · 12 comments

Comments

@anduck
Copy link

anduck commented Oct 8, 2018

Step 1: Describe your environment

  • OS version: Arch Linux
  • Arduino IDE version: 1.8.5
  • MFRC522 Library version: 1.3.6 (1.3.6 being the last stable version. versions above this are unstable)
  • Arduino device: Wemos D1 mini
  • MFRC522 device: RFID-RC522

Step 2: Describe the problem

Found out that MFRC522 with Wemos D1 mini is unstable for at least versions 1.4.0 and 1.4.1. Version 1.3.6 was found out to be stable. Unstability means that sometimes MFRC522 device works, sometimes not. It worked roughly 1 out 10 times, when testing. Reset button was used to reset Wemos device between each attempt.

Steps to reproduce:

  1. Attach MFRC522 device to Wemos D1 mini according to e.g. https://github.com/Jorgen-VikingGod/ESP8266-MFRC522 "Wiring RFID RC522 module"
  2. Get & use MFRC522 library version 1.4.0 or 1.4.1 (via Arduino library manager): sometimes the MFRC522 reader works, sometimes it doesn't
  3. Switch to version 1.3.6: reader works without issues
@Rotzbua
Copy link
Collaborator

Rotzbua commented Oct 9, 2018

Please test a different pin than D3. D3 is also used to trigger programming/run mode.

Is the problem similar to #426?

@Rotzbua
Copy link
Collaborator

Rotzbua commented Oct 9, 2018

@anduck and your esp board version would be good to know. Is it the latest 2.4.2?

@Rotzbua Rotzbua added the need_feedback ↩️ awaiting feedback from people label Oct 9, 2018
@Rotzbua
Copy link
Collaborator

Rotzbua commented Oct 10, 2018

As alternative:

Can you try without connected rst and following code?

#define RST_PIN 0xff // Configurable, see typical pin layout above

This disables the hardware pin based reset. Only the software based reset is done.

@anduck
Copy link
Author

anduck commented Oct 10, 2018

@Rotzbua Tried with RST pin D1. No change in result.

Yes, this is possibly related to #426 .

How can I check my ESP board version? "Get board info" on Arduino IDE shows nothing like 2.4.2.

Tested unconnecting RST pin and added #define RST_PIN 0xff, reader didn't work on 1.3.6 nor 1.4.2.

@anduck
Copy link
Author

anduck commented Oct 10, 2018

Using 1.3.6, I also found out that adding a 100ms delay between mfrc522.PCD_Init(); and mfrc522.PCD_DumpVersionToSerial(); makes it work less often.

@anduck
Copy link
Author

anduck commented Oct 10, 2018

Also found out that while 1.3.6 seems to be stable, it's not. It works maybe 9/10 times. Initialization works everytime and it returns version 0x12.

@Rotzbua
Copy link
Collaborator

Rotzbua commented Oct 10, 2018

How can I check my ESP board version? "Get board info" on Arduino IDE shows nothing like 2.4.2.

Open Boards Manager from Tools > Board menu and search esp8266

Initialization works everytime and it returns version 0x12.

Firmware version 0x12, was sometimes reported. I guess this are malfunctioned boards and/or power issues.

May check your soldering. If flux is on your board clean it with alcohol. Flux can cause unpredicted current flow.

@anduck
Copy link
Author

anduck commented Oct 11, 2018

Ok, thanks. I got esp8266 version 2.4.2.

Did some googling and it looks like version 0x12 is reported by fake boards. Now looking carefully at the board, it indeed does look like a fake. Texts are "bolded" and I can't even read what reads in the main chip in there. Board was bought from ebay.

@Rotzbua
Copy link
Collaborator

Rotzbua commented Oct 11, 2018

Ok, that is bad. I hope you get your money back.
I would appreciate if you can make some pictures and post them to #428.

Can I close this issue?

@anduck
Copy link
Author

anduck commented Oct 11, 2018

I'll get a genuine board and continue testing. I will report back on that, then if this problem doesn't exist for the genuine board, I guess this issue can be closed.

I'll get some pics of this and post to #428

@Rotzbua
Copy link
Collaborator

Rotzbua commented Oct 11, 2018

Thanks 👍

@Rotzbua Rotzbua closed this as completed Oct 11, 2018
@anduck
Copy link
Author

anduck commented Oct 12, 2018

Got a genuine board, running master branch, RST unconnected and it is working properly (stable and reports version 0x92 (v2.0). This means that this issue seems to only be present in the fake Chinese boards.

@Rotzbua Rotzbua removed the need_feedback ↩️ awaiting feedback from people label Oct 13, 2018
Rotzbua added a commit that referenced this issue Oct 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants