We are using a NUC as a replacement for the RPi3 on the robot in order to have more compute power available, and therefore I acknowledge that we are “asking for problems” since this is not a supported configuration, and it’s perfectly fine if the answer is “no”
We have jumpered a 3.3v FTDI device to the UART pins in the Raspberry Pi socket. We are also supplying 3.3v as needed to this socket from the FTDI breakout board. So far, so good. Now, for the strange part: “usually” this setup works great. However, some fraction of cold-boots, maybe 10% to 50% depending on the day, it seems like the MCU gets into an unhappy state when the NUC boots, and refuses to respond to any commands from the Magni ROS node and/or probe_robot or test_motor_board until after we fully cold-reboot the robot via its power button.
To add to the mystery, it seems that the MCU (?) is echoing the bytes back when it gets into this state. As in, if you write a character to the USB-UART, it just echoes the character back but doesn’t seem to do any further type of processing. Cold-booting the MCU appears to “fix it.” I don’t know quite what this means, and haven’t yet attached scope probes to see if this is an “actively-driven” echo or some type of parasitic.
Part of me worries that perhaps some weird data is being sent to the MCU at a high baud rate when the FTDI device is plugged in; the TX/RX lights blink momentarily on the FTDI breakout board we are using, so I wonder if some gobblygook is going into the MCU and making it fall over. Try as I might to remove everything I think might be sending that from my host, (ModemManager, anything bluetooth, etc.), I still see a few LED blinks as Linux boots. I don’t know if this is a red herring though.
any tips to end up with an Ubuntu image that doesn’t send anything on FTDI UARTs during enumeration / driver probing? I have tried various things in udev that I’m happy to share, but I wonder if there is something obvious I’m missing
is there a way to reset the MCU via jumper, etc. from the pins on the motor board? The cold-boot method works fine, it’s just inconvenient.
is there a byte string we should be sending to the MCU when it is in this “stuck” state to cause it to reset or exit whatever mode it gets into? The odd thing is that it’s seemingly random; most of the time the setup boots fine.
Thank you for your patience, and again, we understand this is not a supported configuration and hence we have realistic expectations about the support effort Cheers!