I’ve received my first production run of the fdcanusb CAN-FD USB adapters and they are up for sale at mjbots.com!
While this is necessary for interacting with the moteus controller, it is also a fine general purpose CAN-FD adapter. At the moment, the USB interface is a platform independent line based serial one (Windows, Linux, MacOS). It doesn’t yet interoperate with SocketCAN on linux, but hopefully that will be resolved in the not too distant future.
Finally returning back to other pieces of my quad roadmap, I finished getting an updated power distribution board ready for the quad A0. This board is one I had made many months ago and mostly brought up, but then didn’t quite finish. The r1 was when I first discovered my unfortunate stm32g4 pinout problems that doomed 3 of my in flight boards. The pictures here are of r2, which suffered from yet more pinout problems, resulting in more than my usual number of blue wires. Fortunately, identifying those problems here let me fix them ahead of time for the fdcanusb and moteus r4 boards.
One final piece of porting that needed to happen for the moteus controller r4.x series was the bootloader. The r3.x series has a bootloader, which allowed re-flashing the device over the normal data link, but that was largely specific to the RS485 and mjlib/multiplex framing format. Thus, while not particularly challenging, I needed to update it for the FD-CAN interface used on the r4.x board.
The update itself was straightforward: https://github.com/mjbots/moteus/compare/406f01…1123a9
For now, on the assumption I will in the not too distant future deprecate the r3.x series, just duplicated the entire bootloader, replacing all the communication bits with FDCAN and stm32g4 appropriate pieces. As before, this bootloader is designed to only operate after the normal firmware has initialized the device, and also is required to be completely standalone. To make code size easier to manage, it makes no calls to any ST HAL library and manipulates everything it needs purely through the register definitions.
I introduced the fdcanusb previously, now I’ll describe some of the process and challenges in getting it to work.
My initial challenges were around the PCB design and manufacturing. To begin with, my very first revision was sent out for manufacturing with the same incorrect pinout as the moteus controller r4.0 and thus was only really usable as a paperweight. Second, the supply of STM32G474 chips seems to be spotty now, so for r2 I had to scavenge chips from the boards that had broken pinouts.
One of the necessary pieces for bringing up the moteus brushless controller and for ongoing development with it is being able to communicate with the device on the desk. There aren’t many options for desktop FDCAN communication currently, and certainly none that are in the affordable range occupied by the [CANUSB family of devices](http://CANUSB family of devices) which I’ve used before and was very happy with. Thus I created “fdcanusb”, a USB to FDCAN converter that allows one to communicate with FDCAN devices via a USB interface using a documented protocol, no drivers necessary.
Last time I had an actually hard problem…, a mis-aligned stack which caused randomly misbehaving software. This time, I had a more prosaic problem. One that while not necessarily as interesting, was even more time consuming and frustrating.
The serial port wouldn’t work. I had copied the module I used for DMA based receive and transmit from the STM32F4 and it just wasn’t working. Nothing was written and nothing was received. I carefully inspected the software many times. I looked at the registers in the debugger and nothing seemed obviously amiss. I read the datasheet to look for subtle differences in the theory of operation between the STM32F4 and STM32G4 but came up empty.
In my continued quest to bring up the STM32G4 for the moteus controller r4.1 and other efforts, I get to discover and learn about the million and one ways in which things don’t work on my path to find the one or two ways in which they can work. I recently had an interesting enough problem that it is worth it to signal amplify google searches on the matter for the next unfortunate soul.
Another step in my plan for the next revision of the moteus servo mk2, is an updated controller board. As mentioned in my roadmap, I wanted to revise this board to make improvements in a number of domains:
moteus r4.1 rendering
To verify that I could make FD-CAN work in the next revision of the moteus controller, I made a simple desk setup between two NUCLEO-G474RE boards. I started by soldering up some breakout boards for the TCAN334G CAN transceiver I’m planning on using:
And then wired those up with a lot of jumper wires:
After a fair amount of fiddling, bisecting against the ST CUBE example project, and fixing some problems with my STM32G4 support in rules_mbed, I ended up with some 16 byte CAN frames being sent and received with a data rate of ~4Mbit.
While working on the next revision of the moteus controller, I started by bringing up a software toolchain on a NUCLEO-G474RE board. Unfortunately, even the most recent mbed 5.14 doesn’t yet support that processor. Thus, I have a half-baked solution which pulls in the ST CUBE sources for that controller into the mbed tree as a patch.
https://github.com/mjbots/rules_mbed/blob/master/tools/workspace/mbed/stm32g4.patch
The patch only implements wrappers for the things I care about, so it isn’t a complete solution. Since I am not really using any mbed libraries anymore in any project, that isn’t a whole lot. Right now I’m just using it for the one function that sets up the board, a linker script, and the pin mappings. I will probably eventually just make a rules_stm32 and ditch mbed entirely but for now that is more work than it is worth.
