CLRC663 ATQA but No UID: STM32 SPI Debug Guide

ATQA but No UID: Find the First Failed Exchange

Swipe to view all columns →

What REQA, Anticollision, SELECT and SAK Each Do

Swipe to view all columns →

Check the CLRC663 and STM32 Command Flow

The examples use driver-neutral pseudocode, not a complete STM32 HAL driver. Adapt each operation to your driver and device revision. Bit-field setters must preserve unrelated register bits; CRC helpers must change the enable state without overwriting the Type A preset.

1. Start from a known Type A state

1. Read the documented device version and confirm stable results across repeated SPI reads.
2. Apply the documented ISO 14443A 106 kbit/s protocol profile for both receive and transmit paths.
3. After saving the previous result, set the reader idle, flush FIFO, clear relevant IRQ flags and configure a receive timeout plus a host-side deadline.
4. Do not combine protocol bring-up with antenna retuning or LPCD changes.

2. Send REQA as a seven-bit short frame

uint8_t reqa = 0x26;

reader_idle();
flush_fifo();
clear_irq0_irq1();
configure_timeout();

disable_tx_crc();
disable_rx_crc();
set_tx_data_enabled(true);
set_tx_last_bits(7);         // REQA is a seven-bit short frame
set_rx_align(0);
set_rx_multiple(false);

write_fifo(&reqa, sizeof reqa);
start_transceive();
event = wait_for_exchange_event(host_deadline);
result = capture_exchange_result(event);

REQA does not carry CRC_A, and ATQA must be received without expecting CRC_A. NXP's AN12657, section 4.1, gives the corresponding polling configuration. Accept ATQA only after checking the receive status and two-byte payload; a wait function returning is not a success indication.

For repeated tests, also control the card state. A card in HALT does not answer REQA; use the appropriate wake-up or field-reset sequence before comparing polling attempts.

3. Start cascade-level 1 anticollision

uint8_t anticoll_cl1[2] = { 0x93, 0x20 };

reader_idle();
flush_fifo();
clear_irq0_irq1();
configure_timeout();

disable_tx_crc();
disable_rx_crc();

set_tx_data_enabled(true);
set_tx_last_bits(0);         // Full final byte; preserve DataEn
set_rx_align(0);             // Initial NVB 0x20 round starts byte-aligned
set_values_after_collision(false);
set_no_collision_error(false);
set_rx_multiple(false);

write_fifo(anticoll_cl1, sizeof anticoll_cl1);
start_transceive();
event = wait_for_exchange_event(host_deadline);
result = capture_exchange_result(event);

/* A completed wait is not necessarily a valid response. */
if (result.aborted || result.truncated || result.has_frame_error) {
    report_failure(result);
} else if (result.error_coll_det) {
    inspect_collision_validity_and_resolve_branch(result);
} else if (result.rx_complete &&
           result.fifo_len == 5 &&
           result.rx_last_bits == 0 &&
           bcc_matches(result.rx_data)) {
    save_cascade_level_bytes(result.rx_data);
} else {
    report_unusable_response(result);
}

Transmit framing: TxDataNum.DataEn and TxLastBits are separate fields. For CL1, set TxLastBits=0 to send a complete final byte and keep DataEn=1. With the other bits clear, the REQA-to-CL1 change is 0x0F → 0x08, not 0x0F → 0x00. Preserve KeepBitGrid if your protocol configuration uses it. See the CLRC663 data sheet, TxDataNum register.

CRC and reception: disable transmit CRC generation and receive CRC checking for initial anticollision. Set RxAlign=0 for the initial NVB 0x20 request. Keep ValuesAfterColl=0, NoColl=0 and RxMultiple=0. Read Error.CollDet explicitly; a collision must not be treated as a valid five-byte UID response.

Helper contract: wait_for_exchange_event() observes the relevant receive, error, idle and timer events with a host-side deadline; it returns a reason, not a pass/fail verdict. capture_exchange_result() first saves IRQ0/IRQ1, Error, Status, RxBitCtrl and RxColl. On timeout or an error while reception is still active, it records an aborted exchange and stops the command before reading a stable FIFO length and bounded payload. It must report truncation, preserve the original failure status, and never clear IRQs or flush FIFO before saving the evidence.

4. Check BCC, then SELECT the cascade-level value

For an uncollided five-byte response, XOR the four cascade-level bytes and compare the result with BCC. Then send:

Enable CRC_A generation for SELECT and CRC_A checking for its response. If hardware appends CRC_A, do not also place a second CRC in the transmit FIFO. Check the receive status before accepting SAK; distinguish the over-the-air SAK-plus-CRC frame from the payload your driver exposes after CRC handling.

If the SAK cascade bit is set, retain the UID bytes and continue with 0x95 for CL2. Use 0x97 for CL3 when required. Exclude cascade tags and BCC bytes from the final UID.

Use the Logic Analyzer to Connect SPI Activity to Protocol State

Capture NSS, SCK, MOSI, MISO and the reader IRQ signal. Start by checking transaction boundaries and decoded bytes. SPI writes show what the host sent to the reader; they do not, by themselves, prove what the antenna transmitted.

Separate SPI register writes from the RF command

For a CLRC663 SPI write, the first byte is the register address shifted left by one bit, with bit 0 cleared. The FIFOData register is 0x05; its SPI write-address byte is therefore 0x0A. The examples below show MOSI bytes in hexadecimal, following NXP AN12657, section 2.1.

Keep NSS low for each complete transaction and return it high between commands. These are individual write examples, not an initialization script: configure framing, clear stale state and load the intended FIFO payload before starting Transceive. Check the SPI mode and timing limits for the fitted device revision.

Log one record per protocol stage

Use one format for REQA, each anticollision round and each SELECT. Replace the placeholders with captured values; the stage and request fields identify the operation, while the receiver fields explain its outcome.

Read the record in this order: compare the configuration readback with the intended stage, identify why the wait ended, then interpret error flags, byte count and payload. An empty FIFO alone does not prove that the card is absent, and RxIRQ alone does not prove a valid frame.

Expected lengths belong in the test rules, not in fields presented as measurements: ATQA is two bytes; an uncollided initial cascade response is five bytes. For SAK, account for CRC retention in the receiver configuration. Record the original FIFO length even if the logging buffer is smaller, and flag any omitted bytes.

Worked Example: Clearing TxLastBits Also Clears DataEn

Illustrative analysis, not captured test output. Return to the access-reader scenario: polling works, but the application receives no usable UID after initial CL1. Suppose configuration readback reveals the following values, with KeepBitGrid and the other upper bits clear.

1. Check the hypothesis. Read back TxDataNum immediately before starting CL1. If DataEn is already set and the final-bit count is correct, this example does not explain your failure; continue with the fault-isolation table.
2. Explain the evidence. Seeing 0A 93 20 on MOSI confirms a FIFO write, not transmission of those bytes over the air. With DataEn clear, a correct-looking SPI payload is insufficient.
3. Change only the relevant fields. Set DataEn and clear TxLastBits with a masked update that preserves other required settings. Read the register back again, then repeat the exchange with the same card and position.
4. Verify rather than assume recovery. Require a completed, error-checked response with no unresolved collision, five complete cascade bytes and valid BCC. Then test SELECT, SAK and any further cascade level. Record the actual result, including any remaining failure.

This example identifies a configuration defect; it does not claim a measured success rate or a universal fix. If the framing correction does not restore a valid response, retain the new failure record and investigate CRC configuration, receive state, command completion and RF margin in turn.

Validate More Than One Card and One UID Length

A single four-byte UID does not exercise cascade handling or multi-card collisions. Define the required card families and UID lengths before testing; mark unsupported or unavailable test cases explicitly rather than reporting an untested pass.

Swipe to view all columns →

Define the sample count, success-rate target and operating volume before testing. Report measured results only for the actual PCB, antenna, enclosure, firmware revision and card set.

What to Keep in the Release Record

Use the matrix above as a single acceptance checklist. Attach the PCB revision, reader order code, data-sheet revision, STM32 firmware commit, protocol settings, antenna, enclosure, card set and predefined pass limits.

Retain raw failed exchanges as well as successful selections. Report coverage and measured results for that configuration only; a bench demonstration does not establish performance across an untested operating range.

Using This Test Plan to Evaluate NYFEA NF663

If you are evaluating NYFEA NF663 for an STM32 reader, reuse the protocol checks and log format above as a starting point. NF663 supports ISO/IEC 14443 Type A operation and an SPI host interface; the useful comparison is whether each reader completes the required card-selection tests, not whether a few register names look similar.

Use the NF663 product specification to check interface setup, command behavior and receiver status handling. Keep the application-level test cases, and review or adapt the low-level driver where required.

1. Save the CLRC663 baseline, including firmware revision, test conditions and raw protocol records.
2. Bring up the NF663 implementation using its documented configuration and an appropriate board and RF network.
3. Repeat the same applicable card-selection tests and compare outcomes, timing and recovery behavior. Record hardware differences that prevent a direct comparison.

Conclusion

Start with the first failed exchange and compare what the driver intended with what the reader actually reports. Once single-card selection works, use the same records to validate longer UIDs, collisions and recovery across the intended operating conditions.