moteus hardware CAN ID filtering

Recent improvements to the mjcanfd-usb-1x and the pi3hat were stepping stones to improved reliability for long daisy chains of moteus controllers. Another step in that process is the feature I’ll describe here, hardware CAN ID filtering in the moteus firmware. Let’s talk about how things used to work, what the problems were and how this new feature helps.

The problems

The CAN-FD controller built into the STM32G4 that moteus uses has a complicated set of functionality permitting the firmware to configure it to dispense with frames before the software ever has to see them termed filtering. To date, the moteus firmware has used this for only one reason, CAN prefix support. That means that frames destined for any other moteus controller on the bus will be received by every device on the bus, examined, and then discard in software. Further, the CAN-FD controller will acknowledge those frames on the bus, so senders believe that they have been successfully received. This causes two problems, both of which can result in lost frames and intermittent connectivity.

The first is that if the host is sending frames to many controllers at once, it is possible to overflow the 3 level hardware FIFO on the STM32G4’s CAN-FD controller. If that happens, the moteus firmware may never see frames that were intended for it, as those frames get discarded. The host will just see that as a device that did not respond in a given cycle.

The second problem is a bit more pernicious. If the CAN-FD electrical performance or timing is marginal, or there is a transient EMI effect, some devices may be able to receive a frame but others may not. If the destination of a frame does not receive it, the sender will notice that it wasn’t acknowledged and can automatically retry. You may see the problem here, because if a non-destination device acknowledges the frame, then the sender will never bother attempting to re-send it.

The solution

Configuring the hardware filter appropriately resolves both of those problems neatly. The hardware FIFO will not overflow, because it doesn’t make sense for a host to send many frames in rapid succession to a single host. Also, if only the desired destination actually acknowledges the frame, the host can rely on the acknowledgment to accurately retry transmission when required. These two effects together drastically improve the reliability of moteus CAN-FD communication, particularly when many devices are daisy chained on the same bus.

Upgrading

This fix is transparently available in firmware version 2025-09-20 and newer.

To upgrade, following the instructions in the reference manual, roughly this:

Download the latest firmware from https://github.com/mjbots/moteus/releases

Get the file named YYYYMMDD-moteus-HASH.elf

Issue the following command.

python3 -m moteus.moteus_tool --target 1 --flash path/to/file.elf