The New3DS NFC module was added with 8.1.0-0_New3DS. The Old3DS NFC module was added with 9.3.0-X.
On New3DS NFC module uses the NFC hardware via the i2c::NFC and gpio:NFC services. On Old3DS NFC module communicates with a NFC peripheral via IR with the IRUSER service.
A total of 6 sessions can be open simultaneously for all of these services combined.
NFC services
NFC user service "nfc:u"
This is the NFC service used by regular applications.
This was first seen in the Super Smash Bros eShop demo (only in the exheader, the demo doesn't actually use it), but at that time no system-module was available for NFC on CDN. The first regular application to use this service was Super Smash Bros, with the v1.0.5 game-update, which used the new 9.3.0-21 command set.
NFC management service "nfc:m"
This is used by the amiibo Settings applet.
NFC development service "nfc:dev"
This service seems to be intended for use only on dev-units(or at least some of the command(s)).
NFC service "nfc:p"
This service is used by the mint library-applet, starting with 9.3.0-21. This service was added to the mint service-access-control list with 9.0.0-20.
NFC service "nfc:r"
This service has no known use.
NFC service "nfc:s"
This service has no known use.
"nfc:u" and "nfc:m" command set
There are two different revisions of the NFC module. First version was introduced on New3DS only with firmware 8.1.0-0_New3DS. Second version made its appearance with 9.3.0-X, on both Old3DS and New3DS.
These two versions are not interchangeable and not compatible, since the newer version uses a different command set and has no implemented commands from the older version. This does not introduce compatibility problems since no retail software used the NFC module before the Super Smash Bros for 3DS, whose NFC update required 9.3.0-21.
Post-9.3.0-21
Commands for post-9.3.0-21 have been extracted by analyzing the amiibo Settings applet. Therefore this table may be missing commands. Note that the function name is actually a nickname for easeness of reading, as original function names have been stripped off the binaries.
See IPC Command Structure for an explanation on how IPC communication works and how to use these functions.
| Command Header | Name | Input | Output | Notes |
|---|---|---|---|---|
| 0x00010040 | nfcInit | u8 unknownA | s32 result | |
| 0x00020040 | nfcStop | u8 unknownA | s32 result | |
| 0x00030000 | ??? | void | s32 result | |
| 0x00040000 | ??? | void | s32 result | |
| 0x00050040 | ??? | u16 unknownA | s32 result | |
| 0x00060000 | ??? | s32 result | ||
| 0x00070000 | ??? | void | s32 result | |
| 0x00080000 | ??? | void | s32 result | |
| 0x00090002 | ??? | u32 pid, u32 pidPlaceholder | s32 result | |
| 0x000A0000 | ??? | void | s32 result | |
| 0x000B0000 | ??? | void | s32 result, u32 unknownA, u32 unknownB | amiibo applet ignores value unknownA. It doesn't even read it from the command buffer. |
| 0x000C0000 | ??? | void | s32 result, u32 unknownA, u32 unknownB | amiibo applet also ignores value unknownA for this command. |
| 0x000D0000 | ??? | void | s32 result, u8 unknownA | |
| 0x000F0000 | ??? | void | u32 result, u32 unknownA | |
| 0x00100000 | ??? | void | s32 result, u32 unknownA[24] | |
| 0x00110000 | ??? | void | s32 result, u32 unknownA[8], u32 unknownB[2], u32 unknownC | |
| 0x00120000 | ??? | void | s32 result, u32 unknownA | |
| 0x00130040 | ??? | u32 unknownA | s32 result | |
| 0x00140384 | ??? | u32 unknownA, u32 unknownB, u8 unknownB[48], u32 pid, u32 pidPlaceholder, u32 (buffer_size << 14) | 0x00000002, void * buffer | s32 result | See IPC parameter type 1 for explanation on buffer |
| 0x00150040 | ??? | u32 unknownA | s32 result | Uses something at TLS+0x180 |
| 0x00160242 | ??? | u32 unknownA, u8 unknownB[32], u32 (buffer_size << 14) | 0x00000002, void * buffer | s32 result | |
| 0x00170000 | ??? | void | s32 result, u32 unknownA[42] | |
| 0x00180000 | ??? | void | s32 result, u32 unknownA[16] | |
| 0x00190000 | ??? | void | s32 result, u32 unknownA[8], u32 unknownB[4], u64 unknownC, u32 unknownD | Apparently output is a struct |
| 0x040100C2 | ??? | 0x402), void * buffer | s32 result | |
| 0x04020000 | ??? | void | s32 result, u32 unknownA[16] | Output seems to be a struct |
| 0x04030000 | ??? | void | s32 result, u32 unknownA[41] | |
| 0x04040A40 | ??? | u32 unknownA[41] | s32 result | |
| 0x04060000 | ??? | void | s32 result | |
| 0x04070000 | ??? | void | s32 result, u32 unknownA | |
| 0x04080000 | ??? | void | s32 result, u32 unknownA | |
| 0x040D0000 | ??? | void | s32 result | |
| 0x040E0000 | ??? | void | s32 result, u32 unknownA, u32 unknownB | Again, amiibo applet ignores value unknownA. |
| 0x040F0000 | ??? | void | s32 result, u32 unknownA, u32 unknownB |
Pre-9.3.0-21
| Command Header | Description |
|---|---|
| 0x00010000 | Initialize |
| 0x00020000 | Shutdown |
| 0x00030000 | GetNFCState. This writes an output u8 to cmdreply[2]: 0 = not initialized, 1 = just initialized, 5 = data transfer ready, ... |
| 0x00040000 | This writes an output handle to cmdreply[3]. |
| 0x00050000 | This writes an output handle to cmdreply[3]. |
| 0x00060040 | (u8 input) |
| 0x00070000 | The user process must setup the output-buffer hdr+ptr data @ TLS+0x180 when using this. cmdreply[2] = actual output data size? |
| 0x00080100 | (<0x10-bytes starting at cmdreq[1]>) |
| 0x00090000 | |
| 0x000A0000 | The user process must setup the output-buffer hdr+ptr data @ TLS+0x180 when using this. |
| 0x000B0042 | (u32 size, ((Size<<14) | 2), inbufptr) |
| 0x000C0044 | (u32 size, 0x20, <procid set by kernel>, ((Size<<14) | 0x402), inbufptr) |
| 0x000D0040 | (u16 in) |
| 0x000E0000 | |
| 0x000F00C2 | (u32 unk0, u32 unk1, u32 unk2, ((Size<<14) | 0x802), inbufptr) |
| 0x00100040 | (u32 in) |
| 0x00110040 | (u32 in) |
| 0x00120040 | (u32 in) |
| 0x00130000 | Writes an output u32 to cmdreply[2]. |
| 0x00140000 | This writes an output 0x30-byte struct starting at cmdreply[2]. |
| 0x00150000 | This writes an output 0x2C-byte struct starting at cmdreply[2]. |
| 0x00160000 | |
| 0x00170000 |
NFC module savedata
- "/nfp_backup.dat" Going by the filename this seems to contain data backed up from amiibo.