Product Specs

42 NFCT — Near field communication tag
Page
421
The hardware implementation can handle the states from IDLE to ACTIVE_A automatically as defined
in the NFC Forum, NFC Activity Technical Specification, and the other states are to be handled by
software. The software keeps track of the state through events. The collision resolution will trigger an
AUTOCOLRESSTARTED event when it has started. Reaching the ACTIVE_A state is indicated by the
SELECTED event.
If collision resolution fails, a COLLISION event is triggered. Note that errors occurring during automatic
collision resolution may also cause ERROR and/or RXERROR events to be generated. Also, other events
may get generated. It is recommended that the software ignores any event except COLLISION, SELECTED
and FIELDLOST during automatic collision resolution. Software shall also make sure that any unwanted
SHORT or PPI shortcut are disabled during automatic collision resolution.
A pre-defined set of registers, NFC.TAGHEADER0..3, containing a valid NFCID1 value, is available in FICR,
and can be used by software to populate the NFCID1_3RD_LAST, NFCID1_2ND_LAST and NFCID1_LAST
registers. Refer to the release notes of the NFC stack for more details on the format.
The automatic collision resolution will be restarted, if the packets are received with CRC or parity errors while
in ACTIVE_A state.
The SLP_REQ is automatically handled by the NFC peripheral. However, this results in an ERROR event
(with FRAMEDELAYTIMEOUT cause in ERRORSTATUS) since the SLP_REQ has no response. This error
must be ignored until the SELECTED event is triggered and this error should be cleared by the software
when the SELECTED event is triggered.
42.5 Frame timing controller
The NFC peripheral includes a frame timing controller that continuously keeps track of the number of the
13.56 MHz RF-carrier clock periods since the end of the EoF of the last received frame.
The NFC peripheral can be programmed to send a responding frame within a time window or at an exact
count of RF carrier periods. In case of FRAMEDELAYMODE = Window a STARTTX task triggered before
the frame timing controller counter is equal to FRAMEDELAYMIN will force the transmission to halt until the
counter is equal to FRAMEDELAYMIN. If the counter is within FRAMEDELAYMIN and FRAMEDELAYMAX
when the STARTTX task is triggered, the peripheral will start the transmission straight away. In case of
FRAMEDELAYMODE = ExactVal, a STARTTX task, triggered before the frame delay counter is equal to
FRAMEDELAYMAX, will halt the actual transmission start until the counter is equal to FRAMEDELAYMAX.
In case of FRAMEDELAYMODE = WindowGrid, the behaviour is similar to the FRAMEDELAYMODE =
Window, but the actual transmission between FRAMEDELAYMIN and FRAMEDELAYMAX starts on a bit
grid as defined for NFC-A Listen frames (slot duration of 128 RF carrier periods).
The FRAMEDELAYMIN and FRAMEDELAYMAX values shall only be updated before the STARTTX
task is triggered. Failing to do so may cause unpredictable behaviour. An ERROR event (with
FRAMEDELAYTIMEOUT cause in ERRORSTATUS) will be asserted if the frame timing controller counter
reaches FRAMEDELAYMAX without any STARTTX task triggered. This may happen even when the
response is not required as per NFC Forum, NFC Digital Protocol Technical Specification. Any commands
handled by the automatic collision resolution that don't involve a response being generated may also result in
an ERROR event (with FRAMEDELAYTIMEOUT cause in ERRORSTATUS).
The frame timing controller operation is illustrated in Figure 119: Frame timing controller
(FRAMEDELAYMODE=Window) on page 422. The frame timing controller automatically adjusts the frame
timing counter based on the last received data bit according to NFC-A technology in the NFC Forum, NFC
Digital Protocol Technical Specification.