5. Process Flows

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.

Figure 5-1. Process Flow When Using the NFP Library (Overview)

Initialization Start Tag Detection Tag Detected?  Yes No NFP Tag?  Yes No Access NFP Tag Stop Tag Detection?  Yes No Stop Tag Detection End

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.

Figure 5-2. Initialization Sequence Flowchart

Initialization Sequence Initialize Error Occurs ResultInvalidOperation Already Initialized-Can Continue ResultNeedRetry Retry Success SetActivateEvent SetDeactivateEvent End of Initialization Sequence

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.

Figure 5-3. Finalization Sequence Flowchart

Finalization Sequence Finalize End of Finalization Sequence

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.

Figure 5-4. Common Error Handling Flowchart

Common Error Handling INIT State?  Yes No StopDetection What Is Return Value?  ResultSleep Wait to Wake from Sleep Mode Wake from Sleep Mode Inform User of Need to Retry ResultInvalidOperation Inform User of Error ResultWifiOff Inform User Wireless Is Off ResultTagNotFound Inform User Tag Must Remain Touched Go to Start Tag Detection Sequence

Note:

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.

Figure 5-5. Tag Check Sequence Flowchart

Tag Check Sequence StartDetection Error Occurs ResultWifiOff ResultSleep ResultInvalidOperation Go to Common Error Handling Success Prompt User to Touch Tag to Reader Wait for Tag Detection Notification Received Notification MountRom Error Occurs ResultWifiOff ResultSleep ResultInvalidOperation ResultTagNotFound Go to Common Error Handling ResultNotSupported Inform User Tag Cannot Be Read Success GetNfpRomInfo Error Occurs ResultWifiOff ResultSleep ResultInvalidOperation ResultTagNotFound Go to Common Error Handling Supported characterId?  Yes No Inform User Tag Not Supported Wait for Tag Loss Notification Received Tag Loss Notification StopDetection Inform User Tag Is Supported StopDetection End of Tag Check Sequence

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.

Figure 5-6. Tag Detection Start Sequence Flowchart

Start Tag Detection Sequence StartDetection Error Occurs ResultWifiOff ResultSleep ResultInvalidOperation Go to Common Error Handling Success Prompt User to Touch Tag to Touchpoint Wait for Tag Detection Notification Received Notification Go to Tag Mounting Sequence

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.

Figure 5-7. Tag Loss Notification Waiting Sequence Flowchart

Tag Loss Notification Waiting Sequence RW_MOUNT State?  Yes No Unmount Inform User Tag Must Be Removed Wait for Tag Loss Notification Received Tag Loss Notification INIT State?  Yes No StopDetection Go to Tag Detection Start Sequence

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.

Figure 5-8. Tag Mounting Sequence Flowchart

Tag Mounting Sequence GetTagInfo Error Occurs ResultTagNotFound ResultWifiOff ResultSleep ResultInvalidOperation Go to Common Error Handling Success Check UID?  Yes No Same as Recorded UID?  Yes No Inform User A Different Tag Was Touched to Touchpoint Go to Tag Loss Notification Waiting Sequence Record Tag UID Inform User Not to Remove Tag During Access Mount Error Occurs ResultTagNotFound ResultWifiOff ResultSleep ResultInvalidOperation Go to Common Error Handling ResultNeedRetry Third Retry?  Yes No Inform User Tag Needs to be Reapplied ResultNotSupported Inform User Tag Cannot Be Read ResultNeedRestore Ask If User Wants to Restore Damaged Tag Restore Tag?  Yes No Go to Tag Restoration Sequence ResultNeedFormat Ask If User Wants to Initialize Tag in amiibo Settings Initialize Tag?  Yes No Go to amiibo Settings Start Sequence Go to Tag Loss Notification Waiting Sequence Success Go to Common Information Retrieval Sequence

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.

Figure 5-9. Tag Restoration Sequence Flowchart

Tag Restoration Sequence RW_ACTIVE State?  Yes No StartDetection Error Occurs ResultWifiOff ResultSleep ResultInvalidOperation Go to Common Error Handling Success Prompt User to Touch Tag to Touchpoint Wait for Tag Detection Notification Received Notification GetTagInfo Error Occurs ResultTagNotFound ResultWifiOff ResultSleep ResultInvalidOperation Go to Common Error Handling Success Same as Recorded UID?  Yes No Inform User A Different Tag Was Touched to Touchpoint StopDetection Go to Tag Restoration Sequence Inform User Tag Is Being Restored Restore Error Occurs ResultTagNotFound ResultWifiOff ResultSleep ResultInvalidOperation Go to Common Error Handling ResultNeedRetry Third Retry?  Yes No ResultOperationFailed Inform User Tag Restoration Failed ResultNotSupported ResultNotBroken (Different Tag?)  StopDetection Go to Tag Restoration Sequence Success Inform User Tag Was Restored Unmount StopDetection Go to Tag Detection Start Sequence

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.

Figure 5-10. amiibo Settings Start Sequence Flowchart

amiibo Settings Start Sequence Finalize InitializeParameter StartAmiiboSettings Start amiibo Settings Return from amiibo Settings Go to Initialization Sequence

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.

Figure 5-11. Common Information Retrieval Sequence Flowchart

Common Information Retrieval Sequence GetNfpCommonInfo Error Occurs ResultTagNotFound ResultWifiOff ResultSleep ResultInvalidOperation Go to Common Error Handling Success Supported characterId?  Yes No Inform User Tag Not Supported Go to Tag Loss Notification Waiting Sequence Go to Registration Information Retrieval Sequence

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.

Figure 5-12. Registration Information Retrieval Sequence Flowchart

Pairing Information Retrieval Sequence GetNfpRegisterInfo Error Occurs ResultNeedRegister Inform User Owner Must Be Registered in amiibo Settings Go to amiibo Settings Start Sequence ResultTagNotFound ResultWifiOff ResultSleep ResultInvalidOperation Go to Common Error Handling Blank Nickname?  Yes No Nickname Required?  Yes No Nickname Displayed?  Yes No Nickname Recommended?  Yes No Check if User Wants to Register Nickname in amiibo Settings Inform User Nickname Must Be Registered in amiibo Settings Set Nickname?  Yes No Prepare Substitute String for Nickname Access Application-Specific Region?  Yes No Go to Application-Specific Region Access Start Sequence Go to Tag Loss Notification Waiting Sequence Go to amiibo Settings Start Sequence

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.

Figure 5-13. Application-Specific Region Access Start Sequence Flowchart

Application-Specific Region Access Start Sequence OpenApplicationArea Error Occurs ResultTagNotFound ResultWifiOff ResultSleep ResultInvalidOperation Go to Common Error Handling ResultNeedCreate Go to Application-Specific Region Creation Sequence ResultAccessIdMisMatch Inform User Application-Specific Region Is Already in Use by Another Application and Must Be Deleted in amiibo Settings Before Use, Check if User Wants to Start amiibo Settings Start amiibo Settings?  Yes No Go to amiibo Settings Start Sequence Inform User They Can Continue Without Using Application-Specific Region Go to Tag Loss Notification Waiting Sequence Read?  Yes No Go to Application-Specific Region Read Sequence Go to Application-Specific Region Write Sequence

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.

Figure 5-14. Application-Specific Region Creation Sequence Flowchart

Application-Specific Region Creation Sequence InitializeCreateInfo Error Occurs ResultInvalidOperation Go to Common Error Handling Success Inform User Write in Progress CreateApplicationArea Error Occurs ResultTagNotFound ResultWifiOff ResultSleep ResultInvalidOperation Go to Common Error HandlingResultTimeoutError ResultNeedRetry Third Retry?  Yes No Inform User Must Retry Write ResultOperationFailed Inform User Tag Might Be Corrupted ResultNotSupported Inform User Different Tag Was Touched ResultAlreadyCreated Read?  Yes No Go to Application-Specific Region Write Sequence Inform User Write Is Complete Go to Tag Loss Notification Waiting Sequence

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.

Figure 5-15. Application-Specific Region Check Sequence Flowchart

Application-Specific Region Check Sequence GetTagInfo Error Occurs ResultTagNotFound ResultWifiOff ResultSleep ResultInvalidOperation Check Failed Go to Common Error Handling Success UID Check Pass Fail Check Failed Different Tag Touched OpenApplicationArea Error Occurs ResultTagNotFound ResultWifiOff ResultSleep ResultInvalidOperation Check Failed Go to Common Error Handling ResultNeedCreate Check Failed Application-Specific Region Not Created ResultAccessIdMisMatch Check Failed Created by Other Application ReadApplicationArea Error Occurs ResultTagNotFound ResultWifiOff ResultSleep ResultInvalidOperation Check Failed Go to Common Error Handling Success Integrity Check Pass Fail Check Failed Data Integrity Problem Check Succeeded

5.10.6. Application-Specific Region Read Sequence

This sequence is for reading from the application-specific region.

Figure 5-16. Application-Specific Region Read Sequence Flowchart

Application-Specific Region Read Sequence ReadApplicationArea Error Occurs ResultTagNotFound ResultWifiOff ResultSleep ResultInvalidOperation Go to Common Error Handling Success Go to Tag Loss Notification Waiting Sequence

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.

Figure 5-17. Application-Specific Region Write Sequence Flowchart

Application-Specific Region Write Sequence Inform User Write in Progress WriteApplicationArea Error Occurs ResultWifiOff ResultSleep ResultInvalidOperation Go to Common Error Handling ResultUidMisMatch Inform User Different Tag Was Touched Go to Tag Loss Notification Waiting Sequence Success Flush Error Occurs ResultTagNotFound ResultWifiOff ResultSleep ResultInvalidOperation Go to Common Error Handling ResultNeedRetry Third Retry?  Yes No Inform User Must Retry Write ResultOperationFailed Inform User Tag Might Be Corrupted ResultNotSupported Inform User Different Tag Was Touched Success Inform User Write Is Complete Go to Tag Loss Notification Waiting Sequence

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.

Figure 5-18. HOME Menu Transition Sequence Flowchart

HOME Menu Transition Sequence Data to Write With Flush?  Yes No Display HOME Menu Disabled Icon End of HOME Menu Transition Sequence INIT State?  Yes No StopDetection Transition to HOME Menu Return from HOME Menu Go to Tag Detection Start Sequence

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.

Figure 5-19. Sleep Mode Transition Sequence Flowchart

Sleep Mode Transition Sequence Hold Transition to Sleep Mode RW_MOUNT State?  Yes No Data to Write with Flush?  Yes No Flush Unmount INIT State?  Yes No StopDetection Allow Transition to Sleep Mode Wake from Sleep Mode Go to Tag Detection Start Sequence

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.

Figure 5-20. Power Off Sequence Flowchart

Power Off Sequence RW_MOUNT State?  Yes No Data to Write with Flush?  Yes No Flush Unmount INIT State?  Yes No StopDetection Finalize Exit Application

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.  

Figure 5-21. NFC Reader/Writer Connection Sequence Flowchart


CONFIDENTIAL