This chapter describes the process flow when using the NFP library. It includes an overview diagram and detailed sequences for each process.
The following diagram provides a simple overview of the NFP library process flow.
5.1. Initialization Sequence
This sequence is for initializing the NFP library.
Unless the NFP library is finalized while the application is still running, this sequence is only run once between starting the application and calling an NFP library function.
5.2. Finalization Sequence
This sequence is for finalizing the NFP library.
This sequence is run when the NFP library is no longer required by the application.
5.3. Common Error Handling
This is an example of the sequence used to handle errors that can be returned by any of the functions in the NFP library.
Errors handled with this sequence generally require retrying from the start of tag detection. This example assumes that the same tag will stay touching the device until communication finishes, and an error will occur when the tag is swapped with a different tag.
If the cause of the error can be addressed by the user, make sure to inform the user of how to fix the problem. For example, if the error is caused by the system being in wireless-disabled mode, prompt the user to enable wireless.
If you are using the NFC Reader/Writer for CTR, proceed to the NFC Reader/Writer connection sequence instead of the tag detection start sequence.
5.4. Tag Check Sequence
This sequence checks which character the NFP tag belongs to in an application that does not access the owner information or the application-specific region.
5.5. Tag Detection Start Sequence
This sequence sets the NFC module to start searching for tags and prompts the user to touch the tag to the touchpoint.
Although this step is not included in the flowchart, make sure to provide a way for the user to cancel when waiting for a tag detection notification.
5.6. Tag Loss Notification Waiting Sequence
This sequence is followed when communication with the tag is complete, when a different tag is detected, and when the tag leaves the range of communication of the NFC module.
The flowchart assumes that the application will continue waiting for another tag, but the application does not need to wait for a tag loss notification if it does not intend to continue detecting tags after communication is complete.
5.7. Tag Mounting Sequence
This sequence mounts a tag that was detected by the NFP library.
The flowchart retrieves the tag information and checks the tag UID before mounting the tag just in case any process needs to be resumed due to an error, or a tag that was read in a previous operation needs to be written to.
If a process error occurs and a retry is possible, you do not need to follow the number of attempts in the flowchart.
5.8. Tag Restoration Sequence
This sequence is used to restore a corrupted NFP tag that can still be restored in an application. You do not have to implement the following sequence to restore NFP tags. Instead, you can start amiibo Settings in recovery mode.
The flowchart is designed to restart from tag detection if mounting fails because the tag was removed or a different tag was touched to the touchpoint.
5.9. amiibo Settings Start Sequence
This sequence starts amiibo Settings, which is used for initializing NFP tags, deleting the application-specific region, and other operations.
5.10. NFP Tag Access Process Flow
5.10.1. Common Information Retrieval Sequence
This sequence retrieves the common information recorded to the shared region of the NFP tag.
Determine whether the NFP tag is for a character that is supported by the application. If the character ID (characterId
) is not supported by the application, inform the user that the tag is not supported.
5.10.2. Registration Information Retrieval Sequence
This sequence retrieves the registration information recorded to the shared region of the NFP tag.
The registration information includes the owner's Mii data and the amiibo nickname.
If your application requires the amiibo owner's Mii data and detects an NFP tag that does not have an owner registered, go to the sequence to start amiibo Settings so the user can register the owner information.
If your application requires an amiibo nickname and detects an NFP tag with an empty nickname, go to the sequence to start amiibo Settings so the user can register a nickname.
5.10.3. Application-Specific Region Access Start Sequence
This sequence starts access to the application-specific region in the mounted NFP tag.
If the application-specific region has not yet been created in the NFP tag, go to the application-specific region creation sequence.
If the application-specific region has already been created by an application with a different access ID, the application cannot read from or write to the existing region. The existing region must first be deleted in amiibo Settings. Inform the user and start amiibo Settings.
We recommend informing the user of the differences in how the application works depending on whether it uses the application-specific region. In addition, implement your application in a way that can proceed even if the application-specific region is not used.
5.10.4. Application-Specific Region Creation Sequence
This sequence creates the application-specific region.
If this sequence was entered when the application was attempting to access the application-specific region to write data, you have the data written when nn::nfp::InitializeCreateInfo
is called by passing the data to write as the initialization data to nn::nfp::InitializeCreateInfo
.
If the nn::nfp::CreateApplicationArea()
function returns that the application-specific region has already been created, the content of the region might not be what the application expected.
If a process error occurs and a retry is possible, you do not need to follow the number of attempts in the flowchart.
5.10.5. Application-Specific Region Check Sequence
This sequence checks the integrity of the application-specific region immediately before writing to it.
If there are periods of time when the application does not read from or write to the application-specific region, such as in an application that only reads and writes in between levels, the following kinds of actions can prevent the application from writing to the region. We recommend checking the integrity of the application-specific region before performing a write operation.
- A different NFP tag is touched to the touchpoint.
- The application-specific region is overwritten by another device.
- The application-specific region is deleted in amiibo Settings.
The following flowchart assumes the NFP tag has been successfully mounted.
5.10.6. Application-Specific Region Read Sequence
This sequence is for reading from the application-specific region.
5.10.7. Application-Specific Region Write Sequence
This sequence is for writing data to the application-specific region.
In the flowchart, the application waits for the tag to leave the range of communication after the write process is complete, but if the application will not continue detecting tags, we recommend calling nn::nfp::StopDetection
to stop tag detection until the application needs to start detecting tags again.
If a process error occurs and a retry is possible, you do not need to follow the number of attempts in the flowchart.
5.11. Required Processes in 3DS Applications
Applications on the 3DS require processes to handle various 3DS features, such as the HOME Button, Sleep Mode, and the POWER Button.
5.11.1. HOME Menu Transition Sequence
When the HOME Button is pressed, the application receives a request from the system to transition to the HOME Menu, and the application must determine whether to comply.
If the application cannot immediately transition to the HOME Menu because, for example, it has data that needs to be written, it can display the HOME Menu Disabled icon and reject the transition request.
You must finalize the NFP library to enable the use of NFC features by an applet started from the HOME Menu.
5.11.2. Sleep Mode Transition Sequence
When the system is closed (or when the Sleep switch is triggered on FTR), the application receives a request from the system to transition to Sleep Mode, and the application must determine whether to allow the transition.
If the application cannot immediately transition to Sleep Mode because, for example, it has data that needs to be written, it can hold the reply and continue processing until it is ready for the system to transition to Sleep Mode. When the application allows the transition to Sleep Mode, the system automatically stops tag detection and unmounts any tags. The application must then restart from the tag detection start sequence after waking from Sleep Mode.
5.11.3. Power Off Sequence
When the POWER Button is pressed, the application receives a request from the system to transition to the POWER Menu, and generally the application must immediately run the finalization process.
If some data still needs to be written, the application can continue the write process as long as it can complete within the allotted finalization time.
The NFP library must be finalized before displaying the POWER Menu.
5.11.4. NFC Reader/Writer Connection Sequence
If you are using the NFC Reader/Writer for CTR, you must explicitly connect to the device from the application.
If the nn::nfp::Connect()
function generates an error because the system has transitioned to Sleep Mode or Wireless-disabled mode, handle the error according to the value returned.
If you cannot connect to the NFC Reader/Writer, you must check the reason using the nn::nfp::GetConnectResult()
function and handle the situation appropriately.
If a result of nn::nfp::ResultUpdateRequired
is returned, you must start amiibo Settings to update the firmware of the NFC Reader/Writer.
If a result of nn::nfp::ResultIrFunctionError
is returned, the infrared communication module on the CTR might be malfunctioning. When this error occurs, prompt the user to power cycle the CTR system, and to contact the Nintendo Customer Service Center if the problem persists.
If a result of nn::nfp::ResultNfcTargetError
is returned, the NFC Reader/Writer might be malfunctioning. When this error occurs, prompt the user to power cycle the NFC Reader/Writer and to contact the Nintendo Customer Service Center if the problem persists.
If a result of nn::nfp::ResultConnectCanceled
is returned, either the connection was canceled or there was an internal error. Try connecting the NFC Reader/Writer again.
Sometimes this error occurs because the application itself has called the nn::nfp::Disconnect()
function and disconnected the device.
If a result of nn::nfp::ResultTimeOutError
is returned, the NFC Reader/Writer did not respond. This can happen after you power cycle the NFC Reader/Writer or if it has been placed askew. Try connecting the NFC Reader/Writer again.
After a successful connection, if the NFC Reader/Writer can no longer communicate with the CTR because, for example, it was moved by the user, the state changes to disconnected after one second. Make sure that your application periodically calls GetTargetConnectionStatus
to check whether the state has changed to TARGET_DISCONNECTED
.