[Collection] Bad boards

[Rotzbua]

Hi community,

we often got issues which base on bad manufactured boards. I want this issue as a place to collect known bad boards. Maybe there is a way to detect them.

For example the

Firmware Version: 0x12 = (unknown)

Please only post your pictures or descriptions how to detect those boards. Please do not post any please help me request, they will be deleted.

edit: here a analysis:
https://www.eluke.nl/2018/03/08/fixed-rc522-rfid-reader-not-reading-some-cards-part-1/
https://web.archive.org/web/20200828151219/https://www.eluke.nl/2018/03/08/fixed-rc522-rfid-reader-not-reading-some-cards-part-1/

Best.

[anduck]

I had a Chinese fake board, probably the one discussed here: https://github.com/miguelbalboa/rfid/wiki/Chinese_RFID-RC522

Board reported version 0x12. Had several problems, same ones as mentioned in the link above and in addition some stability issues. For example, board wouldn't find any cards until started again.
Also, the genuine board works from somewhat longer range than this Chinese fake. Not a surprise though.

Pics of fake board, close-up pic of the fake chip and for comparison, a pic of genuine chip:

Fake board:

Close-up of the fake chip.

RC522
12 02
TXD6080
NXP

For comparison, close-up of a genuine NXP chip of a genuine board:

[globalcitizen]

I have seven very similar but different boards function simultaneously on a single bus. My board is very slightly different to both yours and the linked Russian thread however, no MH above top left component, slightly different layout, same color scheme, HW-126 printed between chip and antenna, probably a later revision of the same board.

Cost of these boards is around USD$0.50

[henkiejan1]

I have seven very similar but different boards function simultaneously on a single bus. My board is very slightly different to both yours and the linked Russian thread however, no MH above top left component, slightly different layout, same color scheme, HW-126 printed between chip and antenna, probably a later revision of the same board.

Cost of these boards is around USD$0.50

I have here really the same board and works here like a charm also on 115200Kbps. I buyed it from Worldchips. Firmware 2.0. I use it with a Arduino Mega from Robotdyn. Maybe you have a defective one?

[globalcitizen]

As I have spares I will be happy to mail some to you @miguelbalboa if you want some to test!

[MyNameIs-Nigel]

I have one of the counterfeit chip boards. They seem to wrok fine to me. Whats the big deal?

Firmware Version: 0x12 = counterfeit chip ; Scan PICC to see UID, SAK, type, and data blocks...

[ma-ze]

I have 2 boards:
Board A reports Firmware Version 0x12, seems to work fine though. It looks exactly like the one in anduck's post above.
Board B reports Firmware Version 0x92, ironically this is the one that doesn't work. The chip has no markings at all. Seems to be a different fake, where they got the version number right but the rest wrong? I attached pictures of Board B.

[nedoskiv]

I had many RFID boards, some reported as 0x12, one as 0x92, 0x12 not working, 0x92 working
strange part is that those who report as 0x12 works without any problem on LUA/Micropython, So I assume this library cannot handle them.
Bad part is that all boards that I received from china lately come with 0x12 identification.

[Rotzbua]

@nedoskiv it was reported that following may fix the 0x12 version:

Some boards need more time after PCD_Init() to be ready. As workaround add a delay(4) directly after PCD_Init() to give the PCD more time.

[nedoskiv]

thank you, just tried that, no success. Board detect presense of a card, but was unable to read serial, after that boards hangs - need restart to detect presense of card again.

[JustinOng]

I have a bunch of boards with the same markings as @anduck.

I've found that when more than one reader is connected on the same SPI bus, the MISO bus seems to get corrupted.

When one reader is connected:

0x12 is read out from the version register correctly.

However, when two readers are connected on the same bus:

For some reason, MISO is going low right before being read.

My hunch here is that somehow, the second reader is driving MISO even though CS2 is not asserted.

Strangely, when testing with one known good reader and one counterfeit reader, there is no corruption of the MISO line and the version is read out correctly. If the theory that the counterfeit modules are driving MISO even when their CS pins are not asserted is correct, I would expect the version from the known good reader to be corrupted.

I'm looking to get hold of some tri-state buffers to try isolating MISO when CS is negated.

Would love to hear if anyone has any other theories/suggestions on how to test them.

[nedoskiv]

I'm sure I mention that before: I use RC522 boards mostly on ESP8266 (LUA) ESP32 (MICROPYTHON)
all works fine. On ArdinoIDE I use this library and there is a problem on some boards. Got no why. Other program languages seems to handle all boards well.

[JustinOng]

Could you elaborate on what exactly fails so I could try to replicate it? I've been doing my testing on a ESP32, and I can write/read repeatedly from a card using this library directly.

[Mhaiii]

@Rotzbua Firmware Version: 0x12 = counterfeit chip #501

[SigmaDolphin]

to add to the boards i have one that behaves very different to any examples here
it reports 0x92 version.....when it works....because about half of the time it reports something else seemingly random, i have seen it report 0xFF, 0x88, 0x8C, 0xCF, etc
sometimes it even reads 0x92 and then just stops reading tags, and resetting it makes it go back to reporting weird version numbers, the reader doesn't works at all when the version is reported weird
i already tried using different cables and different Arduinos to no avail, the problem is still there, its VERY unstable

[DarkMorford]

I have a very similar board to the Board B posted by @ma-ze. The markings on the board itself are nearly identical, but the chip on mine is marked:

RC522
19 35
TXD5440
NXP

In software, the device identifies itself as using firmware 0x92. However, the data buffer left behind by the self-test command does not match the NXP datasheet or this library's header:

00000000: 00 be 88 7a 99 ae e1 ae 42 28 ba dc eb bc 63 0b  ...z....B(....c.
00000010: b7 ff c6 bf 10 e3 2f 9c db 5d ed 3d 3c a4 6e 72  ....../..].=<.nr
00000020: e3 f7 e8 b9 6a ac c9 58 d2 90 e5 ac 42 82 b2 2e  ....j..X....B...
00000030: 78 cd ce 10 4d e8 fb 99 2d 62 65 7b 82 c7 57 29  x...M...-be{..W)

Unfortunately I'm not able to get close-up photos of the chip markings. I also haven't had a chance to do any functional testing as far as reading and writing tags. I'm hoping to spend some time on that today, and I'll update with my findings.

[UPDATE 1] During my tests today, I discovered a very peculiar interaction between the self-test functionality and the RcvOff bit of the CommandReg register. In my original test code, I sought to preserve the value of RcvOff and only modify the lower nybble containing the command to start the test. (I.e., I set CommandReg to be (CommandReg & 0xF0) | MFRC522::PCD_CalcCRC.) Since the chip's soft-reset sequence initializes CommandReg as 0x20, the byte being written back was 0x23. In this configuration, I receive the incorrect result I described above. However, if I do not preserve RcvOff and instead simply write 0x03 to CommandReg, the self-test result matches the datasheet listing for this firmware version.

This seems very unintuitive to me. The test is described several times in the datasheet as a "digital self test," and so I would expect a bit controlling the "analog part of the receiver" to have no effect on the results. In addition, the steps listed for starting the test do not mention clearing the RcvOff bit; the soft reset at the beginning of the sequence turns this bit on, and unless it is turned off the test will fail. Has anyone else observed this behavior and/or understand what causes the invalid result data?

[devrim-oguz]

We work with these devices in our company. We have used thousands of these readers and we are getting them from many different sellers. I have encountered many problematic readers but most of them work in some ways. However, I have noticed a correlation between reading performance and the amount of power radiated from the antenna. Some cards have a poor matching, so higher amounts of power needed to read them. So the reader needs to have good matching on the antenna impedance using capacitors. You can't tell this by inspecting visually but it is visible on an oscilloscope screen. Here is an example of three Chinese RFID boards with different rates of success. You can tell which one works better by measuring how much energy is being radiated to the environment. You can measure this using a wire loop connected to an oscilloscope. I have used 4 turns for the measurement wire. I hope you find this useful.

[devrim-oguz]

As a side note; I also tried changing the chips on these readers, it doesn't have an effect on the reading performance on these boards. The good chip on a bad PCB makes the performance poor anyways.

[alastaira]

I have a bunch of boards with the HW-126 marking and sparser layout of smaller components as shown in @globalcitizen's post above. They report Firmware Version: 0xB2 (unknown).
Weirdly, they work absolutely fine with the white credit card tags they came with (at a distance of about 2.5-3cm), but will absolutely not read the blue fobs with which they were also supplied....?

[Vintovin]

I have a bunch of boards with the HW-126 marking and sparser layout of smaller components as shown in @globalcitizen's post above. They report Firmware Version: 0xB2 (unknown). Weirdly, they work absolutely fine with the white credit card tags they came with (at a distance of about 2.5-3cm), but will absolutely not read the blue fobs with which they were also supplied....?

I just bought one to do some early testing, it's also 0xB2, it reads and dumps data without an issue, but it simply wont let me write to the card and tag that came with it, both MiFare 1K's, I'd assume they're counterfit or straight up defective. I've got a pack of 10 EM4035 cards coming, which i'm hoping will work.

[tommy-gilligan]

I have one of these https://core-electronics.com.au/piicodev-rfid-module.html . It reports version 0xB2 but seems to work fine. I haven’t seen much mention of 0xB2 elsewhere online.

[linaspasv]

Anyone seen "Firmware Version: 0x18 = (unknown)". I have ordered 5 boards from the same seller where 2 came faulty, both got "NXP RC522 02 88" written on the chip, while 3 of other working boards got nothing.

[tsamppa]

I am using KMP ProDino ESP32 with Chinese MFRC522 modules in SPI with fw version 0x92 (8 pcs) and a later batch (20pcs) from same seller that reports 0xB2 (20 pcs).
The 0x92 version works a bit better and I could even read and write data to the card.
The 0xB2 version fails the selftest, but still manages to read the UID most of the times. It also fails to read or write data to the card.
None of the 28 modules have any writings on the chip itself.

I also tested PN532 in Grove connector, but it gets rarely detected properly.

[sergiofjpimpao]

Anyone seen "Firmware Version: 0x18 = (unknown)". I have ordered 5 boards from the same seller where 2 came faulty, both got "NXP RC522 02 88" written on the chip, while 3 of other working boards got nothing.

also got one of those in a kit an I can't read anything with it, I may have to buy another one.