Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch does not recognize Arduino Uno #5

Closed
biakkobot opened this issue Oct 7, 2021 · 16 comments
Closed

Switch does not recognize Arduino Uno #5

biakkobot opened this issue Oct 7, 2021 · 16 comments

Comments

@biakkobot
Copy link

Hello! I recently came across this brilliant project, and have been working on implementing it with my Arduino Uno. I had no trouble generating the Joystick.hex file or flashing it onto the Arduino, and my computer now sees it as a Pro Controller. However, when I attempt to connect it using the setup diagram from the README or only with the USB B-> USB A cable, the Switch does not recognize the Arduino as a controller.

As a result, the Python client.py runs without error, but whenever it tries to send a button press, the read_bytes() function returns 0 and the button press is not received. Additionally, when the Arduino attempts to sync with the Switch, the program turns into an infinite loop when ser.in_waiting never changes from 0. (I have tested 19200 and 1Mbps baud values, changing both in avr.h and the client.py argument, but neither were successful).

As far as setup, I'm testing with client.py on my laptop, which is connected to the Uno with an FTDI USB->TTL Serial converter cable as follows: 5V/VCC->5V; GND->GND; TX->TX; RX->RX; CTS and RTS not connected. And the Uno is connected to the Switch dock with the standard USB B -> USB A cable. I tested changing the latency in the COM port settings to 1, 2, and 3 ms, and none of these values seemed to do anything. And from other testing, switching or entirely removing the TX and RX jumper wires did not change the output whatsoever, which makes sense considering that the Arduino's RX/TX lights do not turn on at any point in the process. Any help is greatly appreciated!

@javmarina
Copy link
Owner

Thanks for the detailed report. Seems like you have only used the Python script, which I wrote quickly without much testing and forgot about it. I normally use the Java GUI, which works for me.

The fact that the Arduino is recognized as a Pro Controller by the PC makes me suspect that the error is not within the firmware, but the software running on the computer and sending commands over UART. I would ask you to try the Java programs, which are precompiled here, so you only need Java (8 I think?) installed on your PC.

If that works, it a sign that the Python script is buggy. Otherwise, the only alternative I can think of is using the first firmware version, which emulated not a Pro Controller but a Horipad S. It's simpler, as there is no connection handshake. The firmware is available at this tag.

Let my know if any of that works!

@biakkobot
Copy link
Author

Thank you for the fast response! I just tested it with the Java GUI, and get the error "Couldn't Sync with the AVR MCU" from server.jar. I also tried the Horipad S version, and found the same result. After a little more digging, I'm almost certain the problem is with the UART cable. As it turns out, the GUI output was not affected in any way when the UART cable was unplugged from the Arduino (only attached to my computer via the USB cable). This would also explain why it was working with my laptop but not the Switch.

The COM port shows up in Device Manager, but claims that the device "needs further installation" in the 'Events' tab, which I had previously disregarded. Since this is my first time using this particular cable (or any similar one, for that matter), I started looking into changing/updating the driver, but unfortunately the driver I tried from the ftdichip website didn't seem to help. I'm not sure if I'm doing something wrong or if I just need to try a different adapter. If you happen to have any advice about things to try, I'd love to hear it, but I also don't mean to turn this into tech support rather than discussion of a software issue. Either way, I appreciate the help!

@javmarina
Copy link
Owner

It certainly seems like the issue lies in the serial adapter. My adapter is this one, which has a FTDI FT232RL chip. If I recall correctly, I downloaded the drivers from here.

I would try uninstalling the driver and making sure that you install the correct one before reconnecting the adapter. Another thing you could try is removing the 5V cable, as only GND is needed in order to have a shared voltage reference (though I doubt it will be helpful). Anyway, if the lights of the Arduino Uno don't turn on, the adapter is probably the issue.

@biakkobot
Copy link
Author

Unfortunately, it seems I was mistaken about the adapter. I purchased the one you recommended, and I still encountered the same "Couldn't Sync with the AVR MCU" error when I tried both the Pro Controller and Horipad firmwares. However, this one has some convenient lights for troubleshooting, and interestingly, the TX light did turn on briefly each time I attempted to run the Java GUI. Additionally, the power supply to the Uno is not an issue, as the Power light turns on when connected to the adapter (only with 5V and GND together) and not the Switch. I'm beginning to think the driver is not an issue either, as I tested a few versions from the linked website, and the COM port is consistently visible in the Device Manager as "USB Serial Port (COM5)", which seems correct to me.

Assuming it's not a driver issue, and that I have everything else set up correctly, then I think the problem has to lie in the Arduino somehow. The TX/RX lights never turn on when I run the Java program with the Uno connected through the adapter, but I know they still work because they turn on whenever I flash one of the hex files onto it through the USB cable. I checked the Pro Controller/Horipad device in the Devices page, and I found this in the "Events" section: "Device [...] was not migrated due to partial or ambiguous match." (same message for both). I suppose there's always a chance I'm inputting the wrong port number or something obvious like that, but this might be the issue?

@javmarina
Copy link
Owner

I didn't understand whether you purchased the same adapter as me or not.

If the TX light turns on briefly, that means some data is being sent to the Arduino Uno. The syncing protocol is basically an exchange of small messages between the computer and the Arduino Uno. A successful synchronization requires that the Arduino Uno sends back some bytes. That's what seems to not be happening.

Note that the LEDs in the Arduino Uno don't work as TX-RX indicators, sorry if I didn't make it clear:

  • No LEDs ON: UART is not synced.
  • LED1 ON: "connection lost" mode (synced but not receiving anything from the PC). Sending no presses to Switch.
  • LED2 ON: "connection lost" mode. We gave up and pressed the HOME button.
  • All LEDs ON: UART is synced and we're receiving packets

There are some things that I don't understand:

I checked the Pro Controller/Horipad device in the Devices page, and I found this in the "Events" section

Do you mean the USB endpoint that would be connected to the Switch, or the adapter? My adapter is correctly shown in the Device Manager, under the "Ports (COM and LPT)" category. It is listed as "USB Serial Port (COM3)" and has no warnings. If that is not the case for you, I would try to solve that first (but don't know how 😅). If you meant the USB cable that would connect to the Switch, forget the last words.

Also, could you check what compiler and AVR library you are using? I doubt that's the issue, but the more information I have the better. I'm using avr-gcc 5.4.0 on Ubuntu 18.04 (avr-libc/bionic,now 1:2.0.0+Atmel3.6.0-1 all). You can also check the size of the compiled firmware. For me, it is (last firmware):

Program:    5464 bytes (33.3% Full)
(.text + .data + .bootloader)

Data:        325 bytes (63.5% Full)
(.data + .bss + .noinit)

Make sure that you are compiling with MCU = atmega16u2 in the Makefile. Also, you might already know that there are specific "safe values" for the baudrate. You first compile the firmware with that value in the BAUD macro (avr.h) and then write that one in the Java GUI. If the value is not safe, a warning should appear during compilation. 9600 is a good value. I would advise you against using high values (initially) because hardware/computational/time constraints are obviously higher.

I don't what else to tell you. If you could, you might want to list the complete steps so that I can reproduce the issue. I'm sorry that this is being too cumbersome, I guess troubleshooting is like this sometimes :(.

@biakkobot
Copy link
Author

Interesting, maybe my software versions are the problem. I'm currently using avr-gcc 4.9.2, on Ubuntu 16.04. My terminal output looked like this on the Pro Controller version:

 Device: atmega16u2

 Program:    5490 bytes (33.5% Full)
 (.text + .data + .bootloader)

 Data:        325 bytes (63.5% Full)
 (.data + .bss + .noinit)

(The slight difference in size may be due to my LUFA path, my only other change was the BAUD rate).

And this on the Horipad version:

 Device: atmega16u2

 Program:    3578 bytes (21.8% Full)
 (.text + .data + .bootloader)

 Data:         51 bytes (10.0% Full)
 (.data + .bss + .noinit)

As far as my comment about the controller in the Device Manager, I had plugged it in with the normal USB B -> A cable and was searching for potential issues in the device status pages, it might not have anything to do with the problem. (The Pro Controller device doesn't show up when it's plugged in with the serial port.) And regarding the BAUD rate, I have only tried 9600, 19200, and the 1000000 that was already in the code, and have never encountered a related compilation issue.

I'll try upgrading avr-gcc and possibly Ubuntu as well in the next day or two, and if those don't work, I'll list out what I've done in case I did something wrong along the way.

@biakkobot
Copy link
Author

Tonight I was able to download Ubuntu 18.04 (using VirtualBox) and avr-gcc 5.4.0, and unfortunately encountered the same errors. I'll try to outline everything significant that I've done, hopefully without being too redundant.

As far as equipment, I've been using an Arduino Uno R3 (maybe two years old but used very little, so it's in good shape). I'm still using the serial adapter you recommended, and also tried a cable version with the same results. I have a laptop running Windows 10, and have been running Ubuntu in VirtualBox. And of course I have my Switch dock on the other end.

To create Joystick.hex, I first downloaded the ZIP file for this project and for the Lufa project on my laptop, then extracted both to a shared Ubuntu folder to get them onto the Linux side. I ran "sudo apt install make" to install make, and "sudo apt-get install gcc-avr binutils-avr avr-libc" to get the necessary AVR tools on the new Ubuntu 18.04 install, and edited the makefile to point to the correct LUFA path. Just for completeness, the AVR tools installed were the following, obtained by typing "avr-" and hitting tab twice in the Ubuntu terminal.

avr-addr2line avr-g++ avr-gcov-tool avr-objdump
avr-ar avr-gcc avr-gprof avr-ranlib
avr-as avr-gcc-5.4.0 avr-ld avr-readelf
avr-c++ avr-gcc-ar avr-ld.bfd avr-size
avr-c++filt avr-gcc-nm avr-man avr-strings
avr-cpp avr-gcc-ranlib avr-nm avr-strip
avr-elfedit avr-gcov avr-objcopy

In this case, I replaced the empty LUFA folder in the firmware directory with my LUFA folder. the MCU value had already been set to atmega16u2, so I didn't touch it. Having this set up, I went into the "firmware" directory of the project folder and ran "make". Everything ran smoothly, Joystick.hex appeared. The AVR memory output looked just like what I posted from my last comment, except the byte number had gone down to 5468 as a result of a slightly different path. Because of this, I didn't think my issue could be coming from the different operating systems or from a lack of necessary AVR tools.

I plugged my Arduino Uno in using the USB cable, set it into DFU mode, and used Flip (now on the Windows side again, using version 3.4.7) to flash the newly created Joystick.hex onto the Uno. Checking the Device Manager, the Pro Controller had appeared.

Unplugging the Uno from my laptop, I connected it to the adapter using 4 jumper wires (RX->RX, TX->TX, VCC->5V, GND->GND), then connected the adapter to my laptop. The adapter shows up as 'USB Serial Port (COM5)' in Device Manager. At this point, the adapter power light is on, as well as the Uno's power light (and L light, but I don't think that has anything to do with this project). Plugging the Uno into the Switch dock with the USB cable does not change any of the lights. At this point, everything has been connected.

I opened client.jar and server.jar (still on Windows side), and changed the BAUD rate to 9600. The COM port BAUD rate is set to 9600 in the Device Manager Port Settings (latency timer also set to 1ms, the minimum), and I had changed the BAUD rate in avr.h to 9600 before compiling. "FT232R USB UART" shows up as the default and only option in server.jar's dropdown selection. As far as port numbers, I tried the ones I found from running "netstat" in the Windows command line with various switches, as well as a few others, but none of them seemed to have any effect on the output. In all cases, I get the error "Couldn't sync with the AVR MCU", and at the same time see the TXD light briefly on the adapter. Nothing happens with the Arduino's lights. Unplugging the Uno yields the same error message, with the adapter plugged into the laptop and nothing on the other side. Additionally, nothing has ever showed up on the Switch controller list, regardless of time, programs running, or order of connecting everything. The Switch dock USB port has been tested recently and works fine.

@biakkobot
Copy link
Author

Update: I was doing some searching around, and came across a similar error on wchill's project (wchill/SwitchInputEmulator#12 ). Since I believe your work here was based on that project, I imagine I'm experiencing the same problem that they were. In the comments, they referenced a different offshoot of the Switch-Fightstick library, and surprisingly enough, both shinyquagsire's project (https://github.com/shinyquagsire23/Switch-Fightstick) and progmem's original Switch-Fightstick (https://github.com/progmem/Switch-Fightstick) versions had no trouble whatsoever running on the exact same setup I've outlined here.

Because of this, I'm beginning to believe my setup is built how it should be, and that the issue is coming from something in the software between progmem's work and wchill's. I have no idea what could be different about my specific Arduino, but if you're still interested in trying to look for/fix whatever caused the issue, I'm happy to try anything else on my board for testing purposes. But that being said, I now have a working version with the base features I was looking for, and can do without the extras from this one for my current project. Once again, I very much appreciate all of your time, help, and explanation, so thank you very much!

@aed3
Copy link

aed3 commented Oct 21, 2021

Update: I was doing some searching around, and came across a similar error on wchill's project (wchill/SwitchInputEmulator#12 ). Since I believe your work here was based on that project, I imagine I'm experiencing the same problem that they were. In the comments, they referenced a different offshoot of the Switch-Fightstick library, and surprisingly enough, both shinyquagsire's project (https://github.com/shinyquagsire23/Switch-Fightstick) and progmem's original Switch-Fightstick (https://github.com/progmem/Switch-Fightstick) versions had no trouble whatsoever running on the exact same setup I've outlined here.

Because of this, I'm beginning to believe my setup is built how it should be, and that the issue is coming from something in the software between progmem's work and wchill's. I have no idea what could be different about my specific Arduino, but if you're still interested in trying to look for/fix whatever caused the issue, I'm happy to try anything else on my board for testing purposes. But that being said, I now have a working version with the base features I was looking for, and can do without the extras from this one for my current project. Once again, I very much appreciate all of your time, help, and explanation, so thank you very much!

I am running into the same issue too with my Arduino Uno Rev3. Every problem you've cCould you specify what steps you went through to get the other forks working for you? Are you able to use client.jar and server.jar with the Joystick.hex files those repos generate?

@biakkobot
Copy link
Author

I basically did the same thing as I did with this project, just this time having everything else set up: I downloaded the ZIP file for the project and extracted it into the shared folder to access it in Ubuntu (shinyquagsire's was better to start because I didn't have to manually code inputs to test). I changed the MCU value to atmega16u2, as well as the LUFA path, then ran "make" from the Switch-Fightstick-master directory. I flashed the hex file onto my Arduino, hooked it up, and it worked like a charm.

As far as the JAR files and client.py, they both seem to have the same issues with the new hex file, and I haven't found a different version in any other repos that works (but also haven't looked very far, as my own version will be different enough to where it's probably better to write it myself).

@aed3
Copy link

aed3 commented Oct 21, 2021

I think the combination of the "worked like a charm" part and not being able to use JAR files is what's confusing me. What part is working for you? Can you send button inputs to the Switch, and if so, how?

@biakkobot
Copy link
Author

I'm not sure this is the place for discussing other projects, but in short, shinyquagsire's project essentially converts an image into a long list of instructions and automatically sends the inputs to the Switch. After flashing the hex file from that project, I connected everything, and immediately saw those inputs happening on my Switch. But since I wanted to specify my own inputs, I went to progmem's project, and set it up the same way. To test it, you can see a very detailed explanation in this issue: progmem/Switch-Fightstick#5. Adjust the few lines of code that are mentioned, compile, flash the hex file, and test. I imagine the JAR files have only been programmed and tested for this project, I'm not surprised they don't work with an entirely different one.

@javmarina
Copy link
Owner

javmarina commented Oct 21, 2021

Reply to #5 (comment)

✅ Ubuntu 18.04.6 LTS
✅ avr-gcc 5.4.0
✅ Arduino Uno R3 (as seen on the back of the board, bought from official store)
✅ DSD TECH SH-U09C, with FT232 label on the PCB. Appears as "USB Serial Port (COMx)" on Device Manager. FTDI 2.12.36.4 driver (July 5th, 2021)
✅ Windows 10 (21H1)
❓ Instead of downloading the ZIP file for both projects (mine and LUFA) and then sideloading to the Ubuntu VM, I would do the following: run git clone --recurse-submodules https://github.com/javmarina/Nintendo-Switch-Remote-Control.git in the Ubuntu terminal directly. Then cd Nintendo-Switch-Remote-Control/firmware and finally make. Why?

  • Fast, one line solution. No need to transfer files between OSes.
  • Git is shipped with Ubuntu and most Linux distributions.
  • The --recurse-submodules downloads the LUFA version that has been used and tested for this repository. Might not be the last one. Therefore versions are guaranteed to not conflict.
  • Finally, no need to modify the LUFA path.

I don't want to make it sound like you did it wrong. It's simply a better and easier solution that you might want to use in the future.

sudo apt install make
sudo apt-get install gcc-avr binutils-avr avr-libc
❌ Didn't edit the makefile to point to the correct LUFA path (I didn't have to).
✅ I have the same AVR packages installed.
✅ MCU atmega16u2
make, Joystick.hex appears
❓ "The byte number had gone down to 5468 as a result of a slightly different path". The path you use for LUFA should not affect the compiled firmware size. Our difference is 4 bytes, so I don't think it's a big deal. Data size is the same.
✅ Plug Arduino, set to DFU mode.
✅ FLIP 3.4.7-112 on Windows
❓ Did you do "Device" > "Select..." > ATmega16U2 ??
✅ Flash the firmware
❓ "Checking the Device Manager, the Pro Controller had appeared." I guess you previously disconnected and reconnected the USB, right? Plus, in my case, I only see a "USB input device" In the Configuration app, it appears as "Pro Controller" and a game controller icon.
✅ Connected it to the adapter using 4 jumper wires (RX->RX, TX->TX, VCC->5V, GND->GND), then connected the adapter to my laptop. In my case it's COM3, no effect.
✅ The adapter power light is on.
❌ My Arduino Uno power light DOES NOT turn on, neither does the L light (btw, what is that?). My Arduino is only on when connected with USB (i.e. connected to the Switch dock).
✅ On Windows, I run the two JARs, downloaded from here for consistency.
❓ No need to change the baud rate to 9600 in the Device Manager. When the serial port is opened from the program, baud rate and other parameters (parity, stop bits, etc.) are configured. Latency timer is one parameter that has to be manually configured, because it's specific to FTDI devices.
✅ "FT232R USB UART" selected in server.jar
❓ "I tried the ones I found from running "netstat" in the Windows command line with various switches, as well as a few others, but none of them seemed to have any effect on the output". It seems like you were selecting ports already in use. Nonetheless, your issue lies within the server program, before the connection with the client is established, so the port is irrelevant. There is no need to run client.jar for this troubleshooting.

At this point, when I connect the Arduino to the computer (thus using two USB ports, one for the adapter and one for the Uno), the Arduino turns on. Then I open the server, select the baud rate and click "Open server". The Uno (MCU) is synced and a speed test is performed (in fact, the program warns me that I might need to modify the latency timer because the data transfer rate is slow).

So, to sum up:

  1. Compile and connect adapter to Arduino.
  2. Connect adapter to PC.
  3. Connect Arduino to PC.
  4. Run server.jar (no client.jar needed)
  5. Click "Open server". MCU is synced.

While writing these last paragraphs, I have realised something I did a long ago. The reason why your Arduino turns on when the adapter is connected is because there is a bridge connector between 5V and VCC in the adapter PCB (right?). That means PC powers the adapter via USB, and the adapter powers the Arduino via cable. I recall removing that bridge connector, but it was long ago and don't know why I did it. Try that, check that the Arduino is only turned up when connected with USB, and let me know if it works!

Note: while syncing, LEDs will turn on and off. At the end, only the TX LED should remain on. Also the Switch is not used.

Reply to #5 (comment)

You can't use client.jar and server.jar with other repositories. server.jar syncs with the Arduino using a syncing protocol designed by wchill, so it might work with his repo, but I did other modifications to the firmware (most notably, emulating a Pro Controller, while wchill's is a HORIPAD). The other forks have button presses programmed in the firmware, or the commands are read from physical buttons, so there is no computer involved.

@biakkobot
Copy link
Author

biakkobot commented Oct 21, 2021

I just tried the changes you mentioned, and still encounter the same error. I downloaded the project from the command line, compiled it (did not change LUFA path this time, and ended up with the same byte count you originally had). I moved the hex file over to Windows, and flashed it using Flip (did select the atmega16u2 in the Flip GUI).

It turns out your bridge idea was correct, the Arduino lights did not turn on until connected through the USB cord. (By the way, the L light that I've been referring to is the one between the RX/TX lights and the digital GND pin). I didn't touch the BAUD rates whatsoever, and downloaded a new version of server.jar. However, regardless of whether I plugged the USB cord into the Switch dock or my computer, or of the order the adapter and USB cord were connected, nothing seemed to change, aside from a slightly longer wait before receiving the error when the USB cord was plugged into my computer (didn't do anything different, the GUI just disappears for a brief moment before returning with the error, longer on the first time after being plugged in). The Arduino RX/TX lights still do not come on, while the L and power lights stay constant.

Edit: Part of me wonders whether there's something wrong with my Arduino board. I've been trying several different implementations of the Switch-Fightstick project, and every one of them that uses any kind of serial connection fails at that stage, even though they all claim to work. I might try purchasing a new board to see if that could help at all.

@biakkobot
Copy link
Author

My new board just arrived, and with it I was finally able to get past the error! According to some other tests, my original Arduino board did indeed have issues with serial communication, as the new one confirms that my previous tests should have worked. Once again, thank you for the help! It's a shame it was something so unusual and hard to find, but I suppose that's just how things go sometimes.

@javmarina
Copy link
Owner

Hi! Sorry for the late response. I'm glad that you have been able to solve the issue, even though it was so obscure that you had to purchase a new Arduino. I hope you can continue using my project and feel free to report any issue that might arise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants