NFCT — Near field communication tag

The NFC peripheral is an implementation of an NFC Forum compliant listening device NFC-A.

The NFC peripheral contains a 13.56 MHz AM receiver and a 13.56 MHz load modulator compatible with the NFC-A technology defined in the NFC Forum with 106 kbps data rate.

The received frames will be automatically disassembled and the data part of the frame transferred to RAM. When transmitting, the frame data will be transferred directly from RAM and transmitted with configurable frame type and delay timing. The system will be notified by an event whenever a complete frame is received or sent.

It also supports the collision detection and resolution ("anticollision") as defined by the NFC Forum.

Wake-on-field is supported in SENSE mode while the device is either in System OFF or System ON mode. When the antenna enters an NFC field, an event will be triggered notifying the system to activate the NFC functionality for incoming frames. In System ON, if the energy detected at the antenna increases beyond a threshold value, the module will generate a FIELDDETECTED event. The module will generate a FIELDLOST event when the quality or strength of the field no longer support NFC communication. Please refer to NFCT Electrical Specification for the Low Power Field Detect threshold values.

In system OFF, the NFC Low Power Field Detect function can wake the system up through a reset. The NFC bit in register RESETREAS will be set as cause of the wake-up.

If the system is put into system OFF mode while a field is already present, the NFC Low Power Field Detect function will wake the system up right away and generate a reset.

Note that as a consequence of reset, NFC is disabled, so the reset handler will have to activate NFC again and set it up properly.

The HFXO must be running before the NFC peripheral goes into ACTIVATED state. Note that the NFC peripheral calibration is automatically done on ACTIVATE task. The HFXO can be turned off when the NFC peripheral goes into SENSE mode. The shortcut FIELDDETECTED_ACTIVATE can be used when the HFXO is already running while in SENSE mode.

Outgoing data will be collected from RAM with the EasyDMA function and assembled according to the TXD.FRAMECONFIG register. Incoming data will be disassembled according to the RXD.FRAMECONFIG register and the data section in the frame will be written to RAM via the EasyDMA function.

The NFC peripheral includes a frame timing controller that can be used to accurately control the inter-frame delay between the incoming frame and a corresponding outgoing frame. It also includes optional CRC functionality.

The NFC peripheral has a set of different states. The module can change state by triggering a task, or when specific operations are finalized. Events and tasks allow software to keep track of and change the current state.

See Figure 1 and Figure 2 for more information.

NFC uses two pins to connect the antenna.

These pins are shared with GPIOs, and the PROTECT field in the NFCPINS register in UICR defines the usage of these pins and their protection level against excessive voltages. The content of the NFCPINS register is reloaded at every reset.

When NFCPINS.PROTECT=NFC, a protection circuit will be enabled on the dedicated pins, preventing the chip from being damaged in the presence of a strong NFC field. The GPIO function will be disabled on those pins as well.

When NFCPINS.PROTECT=Disabled, the device will not be protected against strong NFC field damages caught by a connected NFC antenna, and the NFCT peripheral will not operate as expected, as it will never leave the DISABLE state.

The pins dedicated to the NFC antenna function will have some limitation when the pins are configured for normal GPIO operation. The pin capacitance will be higher on those (refer to C_{PAD_NFC} in the GPIO Electrical Specification below), and some increased leakage current between the two pins is to be expected if they are used in GPIO mode, and are driven to different logical values. To save power the two pins should always be set to the same logical value whenever entering one of the device power saving modes. Please refer to I_{NFC_LEAK} in GPIO Electrical Specification for details.

The NFC peripheral implements EasyDMA for reading and writing of data packets from and to the Data RAM without CPU involvement.

The NFC EasyDMA utilizes one pointer called PACKETPTR for receiving and transmitting packets.

The EasyDMA can either read or write between the NFC peripheral and the RAM, but not at the same time. The event RXFRAMESTART indicates that the EasyDMA has started writing to the RAM for a receive frame and the event RXFRAMEND indicates that the EasyDMA has completed writing to the RAM. Similarly, the event TXFRAMESTART indicates that the EasyDMA has started reading from the RAM for a transmit frame and the event TXFRAMEND indicates that the EasyDMA has completed reading from the RAM. If a transmit and a receive operation is issued at the same time, the transmit operation would be prioritized.

Starting a transmit operation while the EasyDMA has already started writing a receive frame to the RAM will result in unpredictable behavior. Starting an EasyDMA operation whilst there is an ongoing EasyDMA operation may result in unpredictable behavior. It is recommended to wait for the TXFRAMEEND or RXFRAMEND event for the respective ongoing transmit or receive before starting a new receive or transmit operation.

The MAXLEN register determines the maximum number of bytes that can be read from or written to the RAM. This feature can be used to secure that the NFC peripheral does not overwrite, or read beyond, the RAM assigned to a packet. Note that if the RXD.AMOUNT or TXD.AMOUNT register indicates longer data packets than set in MAXLEN, the frames sent to or received from the physical layer will be incomplete. In RX, the OVERRUN bit in the FRAMESTATUS.RX register will be set and an RXERROR event will be triggered in that situation.

Note that RXD.AMOUNT and TXD.AMOUNT define a frame length in bytes and bits excluding SoF, EoF and parity, but including CRC for RXD.AMOUNT only, make sure to take potential additional bits into account when setting MAXLEN.

Only sending task ENABLERXDATA ensures that a new value in PACKETPTR pointing to the RX buffer in Data RAM is taken into account.

If PACKETPTR is not pointing to the Data RAM region, an EasyDMA transfer may result in a HardFault or RAM corruption. See Chapter Memory for more information about the different memory regions.

The NFC peripherals normally do alternative receive and transmit frames. So, to prepare for the next frame, the PACKETPTR, MAXLEN, TXD.FRAMECONFIG and TXD.AMOUNT can be updated while the receive is in progress, and, similarly, the PACKETPTR, MAXLEN and RXD.FRAMECONFIG can be updated while the transmit is in progress. They can be updated and prepared for the next NFC frame immediately after the STARTED event of the current frame has been received. Updating the TXD.FRAMECONFIG and TXD.AMOUNT during the current transmit frame or updating RXD.FRAMECONFIG during current receive frame may cause unpredictable behaviour.

In accordance with NFC Forum, NFC Digital Protocol Technical Specification, the least a significant bit from the least significant byte is sent on air first. The bytes are stored in increasing order, starting at the lowest address in the EasyDMA buffer in RAM.

The NFC peripheral implements an automatic collision resolution function as defined by the NFC Forum.

Automatic collision resolution is enabled by default.

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.

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 3. 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.

The NFC peripheral implements a frame assembler in hardware.

When the NFC peripheral is in the ACTIVE_A state, the software can decide to enter RX or TX mode. For RX, see Frame disassembler. For TX, the software must indicate the address of the source buffer in Data RAM and its size through programming the PACKETPTR and MAXCNT registers respectively, then issuing a TXSTART task.

MAXCNT must be set so that it matches the size of the frame to be sent.

The STARTED event indicates that the PACKETPTR and MAXCNT registers have been captured by the frame assembler's EasyDMA.

When asserting the STARTTX task, the frame assembler module will start reading TXD.AMOUNT.TXDATABYTES bytes (plus one additional byte if TXD.AMOUNT.TXDATABITS > 0) from the RAM position set by the PACKETPTR.

The NFC peripheral transmits the data as read from RAM, adding framing and the CRC calculated on the fly. The NFC peripheral will take (8*TXD.AMOUNT.TXDATABYTES + TXD.AMOUNT.TXDATABITS) bits and assemble a frame according to settings in TXD.FRAMECONFIG. Both short frames, standard frames and bit oriented SDD frames as specified in the NFC Forum, NFC Digital Protocol Technical Specification can be assembled by correct setting of the TXD.FRAMECONFIG register.

The bytes will be transmitted on air in the same order as they are read from RAM with a rising bit order within each byte (least significant bit first). That is, b0 will be transmitted on air before b1, and so on. The bits read from RAM will be coded into symbols as defined in the NFC Forum, NFC Digital Protocol Technical Specification.

The frame assembler can be configured in TXD.FRAMECONFIG to add Start of Frame (SoF) symbol, calculate and add parity bits, and calculate and add CRC to the data read from RAM when assembling the frame. The total frame will then be longer than what is defined by TXD.AMOUNT.TXDATABYTES and TXDATABITS. DISCARDMODE will select if the first bits in the first byte read from RAM or the last bits in the last byte read from RAM will be discarded if TXD.AMOUNT.TXDATABITS are not equal to zero. Note that if TXD.FRAMECONFIG.PARITY = Parity and TXD.FRAMECONFIG.DISCARDMODE=DiscardStart, a parity bit will be included after the non-complete first byte. No parity will be added after a non-complete last byte.

The Frame Assemble operation is illustrated in Figure 4 for different settings in TXD.FRAMECONFIG. All shaded bits fields are added by the frame assembler. Some of these bits are optional and appearances are configured in TXD.FRAMECONFIG. Please note that the frames illustrated do not necessarily comply with the NFC specification. The figure is only to illustrate the behavior of the NFC peripheral.

The accurate timing for transmitting the frame on air is set using the frame timing controller settings.

The NFC peripheral implements a frame disassembler in hardware.

When the NFC peripheral is in the ACTIVE_A state, the software can decide to enter RX or TX mode. For TX, see Frame assembler. For RX, the software must indicate the address of the destination buffer in Data RAM and its size through programming the PACKETPTR and MAXCNT registers respectively, then issuing a ENABLERXDATA task.

The STARTED event indicates that the PACKETPTR and MAXCNT registers have been captured by the frame disassembler's EasyDMA.

When an incoming frame starts, the RXFRAMESTART event will get issued and data will be written to the buffer in Data RAM. The frame disassembler will verify and remove on the fly any parity bits and SoF and End of Frame (EoF) symbols based on RXD.FRAMECONFIG register configuration. It will, however, verify and transfer the CRC bytes into RAM, if the CRC is was enabled through RXD.FRAMECONFIG.

When an EoF symbol is detected, the NFC peripheral will assert the RXFRAMEEND event and write the RXD.AMOUNT register to indicate numbers of received bytes and bits in the data packet. The module does not interpret the content of the data received from the remote NFC device, except for SoF, EoF, parity and CRC checking, as described above. The Frame disassemble operation is illustrated in Figure 5.

Per NFC specification, the time between end of frame to the next start of frame can be as short as 86 μs, so care must be taken that PACKETPTR and MAXCNT are ready and ENABLERXDATA is issued on time after the end of previous frame. The use of a PPI shortcut from TXFRAMEEND to ENABLERXDATA is recommended.

In ACTIVATED state, an amplitude regulator will adjust the voltage swing on the antenna pins to a value that is within the V_swing limit.

Refer to NFCT Electrical Specification.

The NFCT antenna coil must be connected differential between NFC1 and NFC2 pins of the device.

Two external capacitors should be used to tune the resonance of the antenna circuit to 13.56 MHz.

The required tuning capacitor value is given by the below equations:

An antenna inductance of L_ant = 2 μH will give tuning capacitors in the range of 130 pF on each pin. For good performance, match the total capacitance on NFC1 and NFC2.

If the antenna is exposed to a strong NFC field, current may flow in the opposite direction on the supply due to parasitic diodes and ESD structures.

If the battery used does not tolerate return current, a series diode must be placed between the battery and the device in order to protect the battery.

NFC Forum, NFC Analog Specification version 1.0, www.nfc-forum.org

NFC Forum, NFC Digital Protocol Technical Specification version 1.1, www.nfc-forum.org

NFC Forum, NFC Activity Technical Specification version 1.1, www.nfc-forum.org