cancel
Showing results for 
Search instead for 
Did you mean: 

ST25R3916B self-tests fail

DaDu
Associate II

Hi

I'm trying to communicate from a STM32WB5MMG via a ST25R3916B to a ISO14443-A tag.

I use the X-CUBE-NFC6 RFAL library with ST25R3916B, RFAL_FEATURE_NFCA and RFAL_FEATURE_T2T set.

Both ST25R self-tests fail:

  • ST25R_SELFTEST returns RFAL_ERR_TIMEOUT
  • ST25R_SELFTEST_TIMER returns RFAL_ERR_SYSTEM (2nd)

Without self-tests, I can read the tag, but writing fails with RFAL_ERR_INCOMPLETE_BYTE.

Can you give me a hint?

Thanks, Daniel

1 ACCEPTED SOLUTION

Accepted Solutions
Ulysses HERNIOSUS
ST Employee

Hi,

your ISR seems to never trigger, letting the code run into timeout. When the IRQ pin goes high  your ISR should kick in and read out the Interrupt status register (MOSI byte 0x5A + 4 more bytes. This never appears in your trace.

The ST25R_SELFTEST is checking among others if the IRQ/ISR are correctly functioning and the timer porting also works.

 

BR, Ulysses

View solution in original post

8 REPLIES 8
Ulysses HERNIOSUS
ST Employee

Hi,

your ISR seems to never trigger, letting the code run into timeout. When the IRQ pin goes high  your ISR should kick in and read out the Interrupt status register (MOSI byte 0x5A + 4 more bytes. This never appears in your trace.

The ST25R_SELFTEST is checking among others if the IRQ/ISR are correctly functioning and the timer porting also works.

 

BR, Ulysses

I forgot to tell that I'm using FreeRTOS …

The RFAL initialization was called too early (while the scheduler was not started yet).

After having moved the RFAL initialization, both self-tests pass. But writing to the tag still fails with RFAL_ERR_INCOMPLETE_BYTE.

Can you give me a further hint?

Thanks, Daniel

Hi,

not sure which function you are using for the writes. It seems you are trying to write page 0x23=35 on a T2T. I presume you anti-collided and activated the tag before?!

With T2T many command responses only have 4 bits (no parity, no CRC). The RFAL signals in this case an incomplete byte error indicating 4 bits. You basically need to interpret the data despite the error. 

In this case the tag was answering 0000b which may mean "invalid page address". Only an ACK (1010b) will indicate success.

Ulysses 

Hi

Yes, the tag is activated. The device types are:

  •  nfcDevice->type: RFAL_NFC_LISTEN_TYPE_NFCA. Should this be RFAL_NFC_POLL_TYPE_NFCA for writing?
  • nfcDevice->dev.nfca.type : RFAL_NFCA_T2T.

The tag is a NXP-NTAG213 (ISO 14443-3A) with 45 pages (with 4 bytes per page). We try to write in the user memory (pages 0x04 .. 0x27).

We write twice 4 bytes with

ReturnCode rfalT2TPollerWrite( uint8_t blockNum, const uint8_t* wrData );

Do the block number correspond to the page address?

Thanks for your support!

Daniel

Hi,

yes, NFC Forum terminology is block number. They are equivalent.

Are you sure the addressed block/page isn't in locked state?

 

Ulysses

Hi

Both lock bytes are 0x0 and the dynamic lock bytes are 0x50, 0x5A and 0x63.

Thx, Daniel

Hi,

if I am not mistaken then the 0x02 inside the 0x5A  means "LOCK PAGE 34-35" being set. Maybe you verify the exact locking state using the manufacturer's tools.

Ulysses

Hi

Thank you very much for your valuable support!

The bytes I wanted to write were locked by the dynamic lock bytes...

With a new a unlocked tag the writing works fine:-)

Daniel