First Steps
The Nucleo-144 has a stackable header system, called “ST Zio”, extended from the Arduino Uno’s:
A subset of these pins is directly compatible with Arduino shields, which could probably be useful. The other set of pins, which aren’t populated with any headers, are called the “ST Morpho”. Every pin on the MCU can be accessed on the Morpho connector, so you can easily solder something up if the expander board is missing something.
This also gives me the name I’ll be using for my board: ZioPilot.
Peripheral Mapping
The first step is to map out the peripherals we need. We need to confirm that the desired features are available on the Zio connector, and I will try to minimize the pins I consume on the Arduino subset of the headers (so that they are available to be used with stock shields). Here’s a snippet from ST’s published schematic for the Nucleo-H755
This is great, most of the peripherals we wanted are already broken out in nicely-grouped sections. If we stick to pins with named functions as much as possible, our routing will be dead simple and our expander board should compatible with other Nucleo-144 boards. Not just the H755, but the F7 series and even something like the U5 (if someone ever wanted to design a controller around that for some reason).
Quick clarification, ST makes a naming distinction between groups of pins on the Zio (e.g., SPIA, SPIB) and functions in the STM32 (e.g. SPI1, SPI2). This is because different Nucleo boards may have different SPI pins/driver numbers routed to those sections. The H755 may have USART2 routed to USARTB, but another board might have USART6. I too will use this terminology in this entry.
Now, on the downside, there’s only one CAN port, and only two UARTs, but we can route plenty of stuff from the many other pins. All the bare minimum things at least can be routed in a universal fashion, then I’ll add a few optional things defaulted to the H755, but make it so those parts can be disconnected and hand-rerouted if needed.
Pin Conflicts
Unfortunately, there are some clashes between pin functions. A lot of this is bad luck with the specific pins ST chose to route to the existing connectors (not just the Zio, but also Ethernet). None of this is a terribly big deal; every pin is still accessible, but this impacts how many features I can use at once and how universal I can make things between boards past/present/future.
SPIA/SPIB MOSI Conflict
I really wanted two SPI busses routed to the Zio; one for my internal sensors, and the Arduino SPI bus left empty for maximum flexibility, but SPIA/SPIB share their MOSI pin (PB5)! WHY!? Two pins literally right next to each other route to the same pin on the MCU. It looks like they originally intended PA7 to be SPIA MOSI, but that interferes with Ethernet, so they use PB5 as the alternate, not noticing, or not caring, that it clashes. Looking across other Nucleo-144 boards, it looks like this is a problem across the board. You have to choose two of the following three: SPIA, SPIB, Ethernet.
I could configure another SPI bus elsewhere (there are 6 available, half of which have 2+ alternate pin assignments), but other Nucleo boards aren’t guaranteed to have SPI that can route to those same pins (I checked). The only SPI bus that is guaranteed to work on all Nucleo-144 boards is SPIA.
So, what I’ll do is route SPIA to my internal sensor bus, but I will put them through normally-closed solder bridges on my expander board, so you can bodge any pins on the Zio to there. This default arrangement will work in the vast majority of cases.
SPIB/SWO Conflict
Additionally, SPIB’s SCK conflicts with the Serial Wire Output (SWO) pin, which is useful for tracing with the debugger. I doubt that will ever be needed/useful, but it’s still a shame. I like that pin. Well, SPIB is already unusable for us, so all I need to do is not wire anything to D23 on the Zio and we’re good.
RMII_TXD1/FDCAN2_TX and USART1_TX/FDCAN2_TX
This one is the worst. For some reason, they picked PB13 for the ethernet TXD1 pin. This pin is all the way on the other side of the chip from the rest of the ethernet TX pins. It’s like ST went out of their way to create this conflict. PG12 or PG14 would have made WAY WAY WAY more sense. It’s also really strange that this is the only ethernet pin that uses an actual shunt jumper (JP6) instead of a solder bridge.
I could remove the shunt from JP6 and bodge a wire from PG14, and maybe I will for rev 2, but I’m guessing that will screw with the signal lengths too much.
So, thanks to this, I need to make USARTA, mutually exclusive with CAN2—damn.
This one almost makes me want to scrap this whole damn project and just design a brand new board from the ground up, but I will control myself and carry on with. Barely anybody needs dual (or triple) CAN, but I will install 3 transceivers so that they can be optionally connected (the F767 supports 3, but the H755 only has 2).
UARTS Are in Short Supply on Zio
I have one guaranteed UART, and that’s it (edit: to clarify, I mean guaranteed to be on specific pins on the expander board; there are many more UARTs, but they will be on different pins for each Nucleo model). The Arduino UART might be taken up by CAN2, or by a shield. There’s also D41/D42 (PE7/PE8), which are not intended to be UARTs, but I will assert, without proof, that most Nucleo-144 boards can put a UART there.
- Since the guaranteed UART (USARTB), has flow control, I’d like to wire it up to a 6-pin JST-GH, to be used with whatever you want to plug in there. It would really be wasted on the IOMCU, which doesn’t need flow control and is one of the least important things really.
- The IOMCU can take D41/D42.
- The Arduino TX/RX will be reserved for one of three mutually exclusive options: CAN2, GPS, or shield.
- I’m scrapping the RC receiver. I admitted last time that it was out of scope anyway.
Anything else will just have to be soldered to the Morpho pads (or Zio if they route there). This is fine. This is largely what I intended originally anyway. We have plenty of UARTs if you don’t care about a little easy soldering.
Final Block Diagram
Apologies for using KiCAD as a block diagram generator. It was the easiest way to scratch this out quickly. I’m doing a weird mix of using wire lines as bundles of wires. I also didn’t align the connectors correctly, nor did I show the pin names or the Zio names for each pin. For that, you’ll have to check out the spreadsheet.
Google sheet of all pin assignments
- MicroSD Slot
- Internal Sensors
- Connected to SPIA, I2CB, and a couple chip select pins.
- The SPI and CS pins are connected through NC solder bridges in case someone has a reason to reassign those pins.
- CAN1
- Connected to the Zio CAN.
- GPIO Controlled terminator (default).
- Solder bridges can be reconfigured to make it permanently on or off and free up that GPIO
- LEDs
- USARTB
- Connected straight to a JST-GH connector
- No need for any jumpers or solder bridges
- Power1 Connector
- Can optionally power the board.
- Analog sense pins for current and voltage
- GPS Connector
- UARTA and I2CA
- Solder bridges to disconnect and reroute if needed.
- Conflicts with CAN2
- CAN2
- Can be used if UARTA is unused.
- GPIO wired to the “standby” pin on the transciever. This means I can use the
BRD_ALT_CONFIG parameter to switch between these two.
- Solder bridges everywhere to disconnect and reroute at will. I put them at both ends to minimize stubs when reconfiguring.
- Terminator is manually configured with a jumper. I was originally going with software control for everything, but it’s too much of a pain. I really only need one reference circuit for that.
- CAN3
- Populated, but not connected to anything.
- Wire it up manually to boards that support a 3rd driver.
- Terminator is manually configured with a jumper.
- IOMCU to UARTC*
- This isn’t actually a named group of pins on the Zio, but I checked three different Nucleo boards and they all have an available UART to route to these pins.
- Solder bridges to disconnect and reroute if needed. I forgot to draw these, but I’m not fixing it now.
- IMU Heater
- I also forgot this one in the diagram!
- I will make this one solder configurable to be controlled by either the IOMCU or a GPIO pin from the FMU
Next Steps
I’ve done the preliminary component selection, but this post is already way too long, so I’ll kick that to the next update. The good news is that I think I can get this all assembled at JLCPCB with parts they have in stock, which is huge.
