rc522 never reads tags on ESP32-S3 (esp-idf SPI) — same hardware reads fine with classic MFRC522 Arduino library

The problem

What type of bug is this? Component Environment

• Home Assistant OS 18.2 / ESPHome 2026.8.2 (add-on: ESPHome Device Builder 2026.8.2), ESP32-S3 rev0.2 (8MB flash, PSRAM), framework esp-idf (ESP-IDF 5.5.5)
• Reader: MFRC522 module (genuine NXP — Firmware Version: 0x92 = v2.0), VCC = 5V, 3.3V IO, SPI mode 0, 4 MHz, GPIO-matrix pins SCK=GPIO12, MISO=GPIO13, MOSI=GPIO11, CS=GPIO10, RST=GPIO21 Problem signature The ESPHome rc522_spi component never completes a card read. Every poll cycle: [W][rc522:145]: CMD_REQA -> OK, but unexpected back_length_ of 0 [W][rc522:387]: Communication with the MFRC522 might be down, reset in 10 Status is OK and an IRQ is seen, but the FIFO level is read as 0 (back_length_), so REQA never yields a valid ATQA and no UID is ever reported (occasionally a garbage nonce like hA-d-5-). Why this is not hardware The identical board/reader/wiring/cards, flashed with the classic Arduino MFRC522 library miguelbalboa/rfid under arduino-esp32, reads all three cards cleanly and reports Firmware Version: 0x92 = v2.0 over the same SPI pins (SCK=12, MISO=13, MOSI=11, SS=10, RST=21). So chip, wiring, cards, power and SPI wiring are all good. Also ruled out
• All SPI pin permutations and both hardware SPI hosts
• update_interval from 150 ms to 2 s
• Two different MFRC522 reader modules
• VCC at both 5 V and 3.3 V
• ESP-IDF and Arduino framework builds (both fail identically; note PR #12420 means ESP32 now uses the ESP-IDF SPI driver under both)
• external_components rc522 from dev: fails with the exact same back_length_ of 0 / "might be down" sequence Expected behaviour REQA/ATQA completes and a valid UID is reported in on_tag. Actual behaviour Never any valid read under ESPHome, on any build, while the same hardware works with the classic library. Logs [22:22:06.388][W][rc522:145]: CMD_REQA -> OK, but unexpected back_length_ of 0 [22:22:07.245][W][rc522:145]: CMD_REQA -> OK, but unexpected back_length_ of 0 [22:22:08.259][W][rc522:145]: CMD_REQA -> OK, but unexpected back_length_ of 0 [22:22:09.271][W][rc522:387]: Communication with the MFRC522 might be down, reset in 10 [22:22:11.270][W][rc522:387]: Communication with the MFRC522 might be down, reset in 10 Boot log also shows [E][spi:020]: Device already registered on the SPI bus. Minimal config esphome: name: rfid-test esp32: variant: esp32s3 flash_size: 8MB framework: type: esp-idf spi: clk_pin: GPIO12 mosi_pin: GPIO11 miso_pin: GPIO13 rc522_spi: cs_pin: GPIO10 reset_pin: GPIO21 update_interval: 1s on_tag: then: - logger.log: format: "tag: %s" args: ['x']

Hypothesis ESP32-S3 MISO sampling with the esp-idf SPI master driver (cf. espressif/esp-idf#7825, IDFGH-6148) or a timing race in rc522's await_transceive_ polling, rather than anything in the reader. The classic library's different SPI/timing path works where ESPHome's does not. Related / references

• espressif/esp-idf#7825 (ESP32-S3 SPI MISO edge/sampling)
• esphome/esphome#12420 (ESP32 Arduino now uses ESP-IDF SPI driver)
• esphome/esphome#14515 (rc522 buffer-bounds fix — behavior unchanged)

Which version of ESPHome has the issue?

ESPHome 2026.8.2

What type of installation are you using?

Home Assistant Add-on

What platform are you using?

ESP32

Component causing the issue

The rc522 component in ESPHome — in your config it's the rc522_spi platform (rc522_spi: ... in front-door-rfid.yaml:39). More precisely, its SPI transceive path under the ESP-IDF SPI master driver on the ESP32-S3: it never reads back a valid FIFO level after REQA (back_length_ of 0), so it can't talk to the MFRC522, even though the chip works fine with the classic Arduino library on the same wiring

YAML Config

Anything in the logs that might be useful for us?

Additional information

No response