Top.SchDoc

Clean up the grid lines in altium. Set your snap grid to 100 mil. Then there is a command to align everything on that grid so there is no crooked wires.
Add designators to all your sheet entries (they can match the file name). This is much better than just "Designator" and will help you during layout.
I think moving the debugger over to this side is much more readable. Also your interface only has SWD, how about including the UART too? Would be handy if you choose to go the black magic firmware route.
To be redundant against any debugger-side circuit issues, consider inlining zero ohm resistors (zohms) to disconnect your STM32 from the on-board debugger. Also still include a traditional FW pin header that you can connect an ST-LINK to should something go awry.
I will make a general feedback section for this kind of stuff but adding zohm resistors and test points would be useful across the design too. In my capstone schematic, I use a ton of test points. You can use the same library as me. The layout of the board also serves as a good example for laying out zohm stuff options and test points: https://github.com/teachee-capstone/teachee
Also, it is good that you have the load switches broken out to connectors but consider the use case that all these signals need a ground return. Consider adding two more connectors that are ground for easy usage. Lack of ground pins was always annoying on the Motec.
Single-ended point-to-point harnesses that can terminate fully on your board will be super useful.
No need to use two separate SPI peripherals for the shift register control. These shift registers can be "daisy-chained" together allowing the use of just one SPI. This will let you save the IO for something else.
You can do plenty of reading about it online but essentially pin Q7S (cascading output) will go to serial input of the next register in the chain. It is also easily extensible in software, clock out 16 bits in a SPI transfer instead of 8 in this case.
I will get into this more I am sure when I look at the shift reg implementation but I noticed you did not run the OE or CLR signals back to the STM32. While they are not strictly needed, they can be quite useful to quickly clear the data and HIGH-Z the outputs.
I see the following LDOs come from the steering PCB (I think). These circuits worked on steering I know, but remember we did have some brownout issues just running neopixels and screen at the same time. I used linear regs because I was in a rush. The current is very limited on these and you will quickly exhaust them with all these switchable 5V loads / outputs.
Given that we have so many 5V outputs and devices drawing off 5V we should go to a buck converter. Especially for the 12 to 5 V reg. for the 5 -> 3.3 V you may be able to get away with an LDO but I still size a larger one.
Check out my blog post on the PMBoard where I designed a buck circuit with the help of TI webench http://portfolio.petetech.net/mock-ecu/
Alternatively you could use something like a V7805 integrated buck like this one: https://www.digikey.com/en/products/detail/cui-inc/V7805-2000/2352134
Ryan C is a big fan of these and we used them this past year as an inline reg to the BSPD. The one I linked above has a 2A rating, which should be sufficient unless you hook up some big 5V loads. (you and Jacob can coordinate with one another on what kind of stuff you'll have). My guess is that this will be fine and they will all be "PSGs" as the great Joe Wigle would say.

I am out of the loop, but what are MC1/2. Consider adding more descriptive net name

Jun 11 '23 03:06 ethanmpeterson

STM32.SchDoc

It is nice that much of this can carry over from prior work. I am going to focus on the parts you have added as the oscillator circuit, bootmode, bypass caps etc is validated by PMBoard and steering.
Designators for all subsheets!
This is a matter of opinion to some extent but I think you could move the CAN transceivers up to the top level and feed them right into the connectors page. I don't know if it flows as well have to take the CAN diff pairs up two sheet levels. Might as well bring the transceivers to the top level so that there is no backtracking. Not sure if this made sense. Can discuss further offline.
The IMU on the other hand makes sense to have as it does not have any external connections. Easy to leave it nested with the STM32.
This red dotted line means there is a naming error. It is saying the net has only one pin. Be sure your port and net names match up here.
Looks good otherwise. One thing you MUST do before fab is feeding all these pin assignments into the STM32 CUBE MX tool. This will let you assign the pins as you have them on your board and verify that it is valid config. Ie the CAN buses can be remapped to the pins you want and in the mode you want. Same goes for the GPIO and SPI etc. The software can confirm that there are no internal limitations in the chip that prevent this config. The reason for this is that some peripherals are shared but can be mapped to different groups of pins. The internal multiplexers do not cover every permutation so it is good to verify.

Jun 11 '23 03:06 ethanmpeterson

IMU.SchDoc

Would consider pasting in the application circuit from the datasheet on the schematic page for reference
This can be cleaned up
Make one 3V3 connection. Place the caps directly next to one another. Much more readable. Just remember to follow any layout guidelines on capacitor placement.
I agree that SPI will probably be easier to debug and work with rather than I2C. I have used these ICM IMUs and they can be annoying to write drivers for.
The ports are swapped I believe SDI is going to SDO. As a cheatsheet
- SDO = Serial Data Out which is connected to MISO on the STM
- SDI = Serial Data In which is connected to MOSI on the STM.
You should also consider capitalizing the port names. Just to be consistent with the rest of the design.

Fix the wire swap and it should work!

Jun 11 '23 04:06 ethanmpeterson

CAN.SchDoc

Nothing to say here. Termination switch mistake is addressed. Looks good to me.
Maybe add a note for layout to indicate which switch position enables bus termination in silk screen

Jun 11 '23 04:06 ethanmpeterson

Connectors.SchDoc

Seems reasonable overall. Not sure if a dedicated page is really needed.
You should consider adding some capacitors on the 12 V connectors. Bulk caps are good to smooth things out off the battery, Also consider adding a TVS diode.
It would be ideal to have some kind of protection at this point too since blowing up an ecu with a backwards connection would be expensive. You could have a load switch whose enable line is pulled VBATT. That would ensure a correct hookup.
Before the load switch itself, you could also have an overvoltage protection PMIC. This stuff is best practice but optional. Bare minimum is some capacitance and TVS diode.
I would use a set of 22uF ceramic caps in parallel for minimal ESR.