7 BLOWN PORTS IN LESS THAN A WEEK!?!? What a joke.

[technik3k]

@TriDragon, I also find this part very interesting:

@Keith_Horton1826

… I also decided to update the firmware on the cortex, joystick, and batteries. After doing the update, one of my ports came back, so I was down to 2 blown ports. …

According to @nenik in V5 motor wiring thread, FPGA is handling motor communication interface:

@nenik

RS485 is the physical layer, by definition a half-duplex link.
The “link layer” would be that it uses USART-like signaling (start bit, 8bits, no parity, 1 stop) at 1.5625Mbaud
(pretty bad baud rate, 25MHz/16, hard to get common serial ports - off a 12 or 24MHz xtal, synchronize to this).
There is no addressing whatsoever - each port is really a dedicated point-to-point link, the CPU really has 25-some serial ports attached to it (implemented in the programmable logic around the ARM cores in the central ZYNQ7 chip), so what could you call the network layer is that each attached device keeps sending a frequent periodic status packet, to which the brain answers with a form of ACK or, if there is one ready, a command packet.
Yes, you read that right, the communication is initiated by the devices and it’s the brain that answers.

The motor talks in 16B fixed size messages. 16B status, 16B ack or command with the only framing being the delays for bus turn-around and between the messages.

So, what happens when you, for example, set a motor rpm on port 13?
First, the VexOS runtime assembles the command packet (16B), stores it in a buffer accessible to the programmable hardware dedicated to the port 13 and raises a flag. That’s about all from the SW point of view. Next, on the motor’s own schedule, the motor starts streaming its 16B status packet on its own dedicated wire and through ZYNQ-implemented USART HW, which DMAs it into another shared memory buffer dedicated to port 13. Once the status packet is received, the HW notices the flag and starts streaming the premade command packet (otherwise it would stream an ack packet).
Since all that happens using DMA and dedicated, per-port HW, all the devices can talk at the same time, while the brain can work on its own schedule (but still rather fast) to process the incoming data.
Last time I checked, the motors were sending the updates every 5ms…

Could it be that I/O block on the FPGA has multiple paths for input data and in some cases not all paths are destroyed by an ESD and, if firmware update reconfigured which paths are utilized, then some ports are potentially recoverable?