Mysterious MCU comms issues sometimes (in an unsupported configuration)

codebot · December 16, 2019, 7:16am

Greetings!

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!

mjstn2011 · December 17, 2019, 5:08pm

The main board with motor drivers for the Magni we call the MCB or Motor Controller Board or some people call it the Master Control Board. So I think when you say MCB you mean that large main board.

You have not stated which version of the MCB you are using, please identify it per this page https://learn.ubiquityrobotics.com/PC_Board_RevId

For issues involving the serial interface the baud rate is as you would know 38400 and is fixed.
For your work I would strongly suggest if you don’t have it yet a serial analyzer of some sort, many are getting cheaper all the time. Perhaps take a look at EZ-Tap from Stratus Engineering if you have no analyzer as the EZ-Tap works with some pc software.

I hope you already have this document if you are trying to replace the raspberry Pi.

github.com

UbiquityRobotics/ubiquity_motor/blob/indigo-devel/Serial_Protocol.md

# Ubiquity Robotics Motor Controller Serial Protocol V3

## Packet Structure
`0x7E AA BB CC DD EE FF GG`

### `0x7E` : Delimiter
This is the start character of the protocol, Motor controller looks for this character along with the Protocol Version to establish the validity of the incoming protocol.

### AA : Protocol Version and Message Type
The most signifcant 4 bits are the protcol version (currently 3), and the least significant 4 bits are the Message Type (READ/WRITE/RESPONSE/ERROR).

### BB : Address
This specifies the register address the command is to be acted on.

### CC DD EE FF : Data
Data is a BIG ENDIAN representation of the information being sent.
It has 4 bytes of data - 8 bits each, that together represents a 32 bit data string.

Negative numbers are represented using 2s complement:
+568 = 0x00000238

This file has been truncated. show original

We do not have much other published information on usage of the MCB without our Raspberry Pi and I appologize for that. We have been very actively improving the pages on https://learn.ubiquityrobotics.com/ but as I said, not much on this level of detail for use of MCB by itself.

The next version of the MCB, version 5.2, has a reset switch on it to answer one of your questions. For your board at this time you can safely ground pin 3 of JT201 jack which is labeled XRES.

The MCB firmware comes up and immediately starts to transmit assorted state/status messages once it is ready to go. So you could wait for the status packets before you send anything and that may be helpful to solve your issue if it is related to the startup sequence.

Mark

rohbotics · December 19, 2019, 2:31pm

Hey Morgan,

Just a quick couple things to check.

Make sure that you don’t have getty running, this will print shell prompts and things to the serial port. Also
Check your grub command line for serial output. I forget whether the default is to print to serial or not, but this could be the reason you are printing junk to the serial lines.

Also when you say it is echoing all the characters back, is it echoing them back exactly, or with extra junk on them? (Open up minicom and see what happens when you type).

Rohan