ndeadly
Amiibo Error when playing a amiibo-supported game
Switch Firmware Version
Other (please specify in issue description)
Atmosphère Version
1.3.2 (Latest)
Mission Control Version
0.7.0 (Latest)
Boot Method
Hekate
Issue Description
I use FW 14.1.2. When I play a game (Splatoon 2 is what I played) it gives me an error before joining a battle (in image below) in syscfw. I suppose this is because of the switch not detecting the amiibo sensor in the pro controller. I used a PS5 controller btw.
Error Report
Additional Context
No response
@Banz99 reported this issue to me some time ago, but we never finished looking into it. It seems that the nfc module is requesting some data from the controller that we are unable to fake correctly due to not understanding its meaning.
Maybe, instead it's possible to tell the Switch that a controller doesn't support NFC. There's nothing documented, but there are a few unknown data fields sent when the controller identifies itself that may contain a flag for this or similar. I don't own Splatoon 2 to test, but maybe you could give this build a try and see if the error still occurs.
MissionControl-0.7.0-amiibo-fix-dca863f.zip
Maybe it would be useful to sniff a third-party supported controller that doesn't support Amibo if any exist?
Absolutely, but don't own one or even know if they exist. Maybe some of the 8bitdo controllers? I would be curious as to whether any of them also trigger this error message or not.
Yup, I tried the new build and trhe issue is still here. Doesn't work unfortunately :( Update: Now, it gives me the error more often (when I come back to the plaza). Seems like it made it worse.
That's unfortunate.
It seems as though the 8bitdo controllers did have a similar sounding issue at some point, and it was fixed in newer firmwares, eg.
- Fixed the pop-up window error when using amiibo.
https://github.com/fwupd/8bitdo-firmware/tree/master/releases/M30/1.13
If I can find someone with one of these controllers to log some of the communications, it might shed some light on the fix. Certainly easier than doing a bunch of RE to figure it out.
Unfortunately I don't have an 8bitdo but I do have a few controllers (ps4, ps5, wiimote motionplus). If you need any help and/or need someone to debug on these ones, don't hesitate to contact me. 👍
I'm willing to bet they ran into the same issue and just fixed the issue in firmware
Unfortunately I don't have an 8bitdo but I do have a few controllers (ps4, ps5, wiimote motionplus). If you need any help and/or need someone to debug on these ones, don't hesitate to contact me. 👍
It needs to be a controller that uses the Switch protocol already and doesn't trigger this error, so that I can see what it's doing differently. For everything else, it's Mission Control that's responsible for what they "send" to the console so they're of no use here.
I'm willing to bet they ran into the same issue and just fixed the issue in firmware
Well yeah, that's the point I was making linking the firmware changelog :p
Hi! I happen to have 8bitdo's Gamecube Bluetooth adapter that shows GameCube/Wii controllers as Pro Controller. Maybe I can help logging that info? I also have same errors when playing Splatoon 3 Demo with Dualsense
@fagirton unfortunately that won't help, as Bluetooth adaptors are seen as USB controllers to the system. It needs to be a direct Bluetooth connection so I can log it.
Hey, I tried Splatoon 3 and I am receiving this error more often, any leads?
I've done a bit of work on making the controller emulation more accurate and actually respond to the console's NFC queries, but so far it doesn't seem to be enough. I still don't understand the meaning of the data sent by official controllers.
I'm not sure if it's considered an official controller or not, but I do have one of the PowerA Wireless Gamecube style controllers which connects to the switch using stock OS but doesn't have an NFC reader at all so no amiibo functionality. What do I need to do or run on my switch to get the info you need?
@Sinthrill that sounds perfect if it can be used without triggering Amiibo errors in games. Do you own a copy of Splatoon 2?
If so, or you know of another game that can trigger an Amiibo error, install this build and reboot, load the game up and go to where you would trigger the error dialog, then post the mc-mitm.log file it creates on your sd card. In Splatoon 2 you can trigger the error by attempting to access the Amiibo "machine" located behind you when you load into the main lobby.
MissionControl-0.8.0-debug-logging-7eafa57.zip
Booted up BOTW and got a different amiibo error about connecting a compatible controller so something in this log hopefully gives some insight mc-mitm.log
Do you get this same error without Mission Control running? That log shows no attempt to read NFC data, only the initial handshake. This could mean that HOS is simply identifying the controller by it's name (or otherwise) and assuming that because it's not an official Pro controller that it doesn't support NFC. I will have to compare to an official controller and see if any other flags are set.
Yes I got the same error with this controller prior to installing Mission Control again since updating to HOS 15.0.0. Disconnected all controllers from the system through settings, rebooted and immediately re-paired the controller and attempted the amiibo registration in the settings. Hopefully this log is a little more insightful, though it doesn't look terribly different from the first one mc-mitm.log
It looks to just show a second connection attempt. Nothing new. I will try a few things after work today with the parameters your controller is sending. I would still be curious to see what happens with Splatoon, but I guess you don't own a copy if you're testing this with BOTW.
No unfortunately I don't own Splatoon. I know SmashU and MK8 Deluxe both support amiibo so I gave them a shot as well. This log also includes my joycons connecting since I was in handheld mode but I disconnected them before trying the amiibo stuff in those two games, dunno if the info from them helps any or not. I have a friend that might have a Pro controller that I can connect to get a log for. mc-mitm.log
Thanks, appreciate you taking the time to investigate. I will have to check later whether this new log contains anything interesting. At a glance, still no attempts to read NFC data. Maybe it's something specific to Splatoon. I have also seen random Amiibo errors in SMO while just running about on the first level. No idea how to reliably trigger them though.
I didn't realize SMO has amiibo functionality. I can give it a shot and try to get one of those errors with this controller. You had those errors just running around at the very start of the game, Cap Kingdom? Also just heard from my friend that had a pro controller. He sold it when he sold his Switch but has since bought an OLED switch and plans on buying another pro controller tomorrow so hopefully I can do some testing tomorrow with it.
Yeah, the way you use the amiibo in Odyssey iirc is by talking to the roomba lol
I didn't realize SMO has amiibo functionality. I can give it a shot and try to get one of those errors with this controller. You had those errors just running around at the very start of the game, Cap Kingdom? Also just heard from my friend that had a pro controller. He sold it when he sold his Switch but has since bought an OLED switch and plans on buying another pro controller tomorrow so hopefully I can do some testing tomorrow with it.
Neither did I until I got a couple of these errors. It's been a while since I played, but from memory it would occur in the flat area just after crossing the stone bridge over the water in cascade kingdom. I never really figured out how to trigger it consistently. No worries about the Pro Controller, I have one myself I can use for testing.
Okay so I spent some time googling and came across this glorious chunk of info you probably know about Bluetooth HID Subcommands and dug a little into my log file for the BT Gamecube controller I have. Turns out some things listed as "always x or y" are different with this controller when reporting device info.
[ts: 22058ms t: mc::HidReportThread p: 17/17] <- HID Command Response [0x02]: 82 02 03 89 **06** 02 00 0b e4 73 41 83 **03** 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 38
The start is as usual, 82 02 is controller saying it's replying. 03 89 is firmware version. But then the 06 after, according to that info should be 01 for JCL, 02 for JCR, or 03 for Pro controller. Then we've got the typical 02 followed by MAC. Then we have an 03, which according to the datasheet is always 01. Might it be possible that one or both of those things are what's telling the Switch that this controller can't do NFC?
Yeah, this is exactly what we've been looking at already. It's why I wanted a log from the licensed controller in the first place. The info on parts of that repo is a little incomplete or outdated. The 06 means it's a Licensed Pro Controller, so that's fine. @Banz99 played around with some of those bytes for me but didn't notice any difference in the behaviour. I think we will have to properly emulate the nfc responses to be honest.
Actually, an interesting experiment could be to go the other way and see how much we would need to change to make a real Pro Controller look like the licensed one to the point the console stops trying to do nfc with it. Could give some information on what the console is using to determine whether to do the nfc stuff or not. However, we probably can't significantly change the controller type information without negatively impacting other things though. For example, pretending to be a licensed controller instead of official removes the ability to use the native button remapping or stick calibration features of HOS.
With the licensed controller I have I am unable to do button mapping or motion control calibration, but I am able to use the stick calibration in the settings. Maybe that even varies among various licensed controllers?
EDIT: Though based on what I've read the controller itself does support motion controls which I've tested in BOTW and they do work. Just no rumble or IR/NFC support. It's this controller specifically that I've been using.
I may have misremembered regarding what you can and can't do with a licensed controller, but the point remains the same - that we likely lose features by telling the console we're a licensed controller.
The issue is pretty much understood, needs nfc communication to be emulated correctly. That's still not done.