Design review request - dual RP2040 dual motor board

Hello folks!

I have been having great success with my RP2040 motor controller boards, with many thanks to @runger for his excellent work supporting the RP2040 with SimpleFOC.

I am completing the second rev of my Dual RP2040 controller which features more I/O as well as CAN bus. The previous rev of the board is working but I did have a catastrophic failure due to some kind of lockup, so I have done my best to reduce the impedance of traces relating to mosfets or their drivers.

I would appreciate any design feedback. All of the files are on our github here. Please take a look:

Thank you!
Taylor Alexander

5 Likes

I stuck it up on Altium here but it seems they demand an Altium account before it’s viewable now.

1 Like

Cool board!

I get some errors when opening the layout file, I’m not sure why, even trying to open the .kicad_pcb file directly does not work. Did you set something custom up for filepaths or anything?

I saw you allocated some pins for EMO (nice!) but I’m confused the difference between CPU_ESTOP and ESTOP? And CPU_ESTOP, CPU_ESTOP_AUX are not routed anywhere external, just between mcu?

Also, I’m curious why choose W25Q16 16MBit flash instead of W25Q128, the price difference is so small? A lot of people on the forum here had issues with running out of flash to run SFOC with some extra peripherals, it might save you headache later.

I would suggest that instead of doing like this:


Just to put the purpose as the net name, when trying to see what is connected to what A3_2 kind of obfuscates the purpose, but you assign a net later (TH1) which is useful and indicates what the pin is for. Also, I would group the blocks by function, like put the flash next to each other, etc - I had a hard time finding misc peripherals. Also, you can use the text field to put some additional detail to show what goes to what, like inter-mcu serial bus (using the EDA software, it’s easy to find connected nets with ~ but if you are looking at the PDF file, it’s impossible to find).

I would split your MCU page into A and B, one for each MCU with the connected peripherals so it’s clearer what is doing what, with some inter-sheet pins to show when things are going out of the local area. It will make it more readable

You should also change the name for the crystals, I don’t think any of them were labelled - for example rp2040 requires 12MHz clock, but the names for clocks are Crystal_GND_24. But your CAN translator also need a clock, but the frequency is not shown - this makes creating the BOM more difficult and much more difficult to identify replacement parts if anything you are looking for is not available.

Just wondering, does your application use both cores? I was wondering about doing dual motor control with one SFOC loop per core, I don’t know if anyone else did something like that yet.

I think the MOSFET drive circuit looks good, I know the datasheet for your driver does not suggest any pull-down on the gate for the MOSFET but I would put the footprint as DNP - if you end up needing this it will be helpful, but also I understand if it’s too late to modify layout for a small thing like that.

Also, I saw you are using CAN-serial translator, did you see the can2040 PIO implementation by Kevin O’Connor? GitHub - KevinOConnor/can2040: Software CAN bus implementation for rp2040 micro-controllers, it might save you some BOM cost if you have one PIO engine available, and it seems pretty robust.

4 Likes

This is really cool, and I would like to have a closer look at things so I can make some more constructive criticism in the future, but the main thing that stands out to me is that you are combining basically two boards into one? Why not just have one board per RP2040?

I was using the B-G431B-ESC1 which I think has 128kBytes of memory, and it seemed to be ok. The Lepton has 64 and that is definitely too small.

I have become very much partial to the idea of separating waveform generation from everything else. Waveform generation is by far the most time critical task for many things. It appears to be interfered with greatly and it quickly becomes difficult to write even slightly complicated code when you have to return quickly and do everything fast.

If one core of the RP2040 can do waveform generation while everything else is done by the other core, that would definitely be a good idea. As long as it can be done practically, I have unfortunately had bad experience trying to use the second core, it is prone to crashing, however it depends what you are doing on it. Other people keep saying dividing tasks like this is a bad idea, but to be honest I have never heard any criticism that holds water. The set electrical angle and open loop functions don’t even reply, they don’t send any information back, or don’t have to. They take one or two parameters and do their thing. That’s it. Just like a PWM peripheral, except it produces a 3 phase sine (or whatever) waveform. Such things are also extremely common and clearly a good idea for 2 phase motors such as stepper motors, where we often use stepper motor drivers. Why not do the same for 3 phase motors?

I am already having issues with the lack of floating point that the lepton has when compared to the G431. The RP2040 also does not have floating point. So this is a factor for some applications. However it might be ok.

At a high level I think it is more advisable to have one board per MCU. This makes it a more useful building block. You use as few or as many as you need.

Actually fleshing out the details of the support within SimpleFOC for the hardware of the RP2040, and even leveraging it to maximal advantage, appears to be a substantial fraction of the undertaking.

I used to kind of dislike the idea of a HAT, i.e. an add on module analogous to an arduino shield. However I think it is not such a bad idea, now. The Pico boards are $5.5 each, and available as components, which can be soldered down surface mount style with the castellated edges. It saves you from some of the complications and overhead of redesigning the Pico board as you integrate it into your design, and I don’t think the sum of the BOM is going to be a lot less than $5.5… with these small numbers of units being produced such shortcuts appear to me to be a good idea. But I guess you already did the design work now…

I am not a fan of “versions” or “configurations” that are woven together. This business gets complicated fast at the best of times. I think there should be clearly separate repositories for every single exact, complete design. If you try to make things mix and matchable things rapidly become ungainly and hard to get working reliably. At least starting with one single exact complete design is definitely a good idea.

Hey @Taylor_Alexander, looks like an awesome new version of your driver board!

I saw you’ve already received a super-detailed and very professional review on GitHub. I don’t have much to add to that :slight_smile:

One thing perhaps to look at is the CAN termination seems doubled, if you have a DIP-switch you don’t really need a jumper?

Do I also see correctly that they communicate with each other via a UART connection? And that there is only one CAN controller, connected to one of the RP2040s?
→ I can’t quite follow the CAN bus connections - the controller seems to output CANH0/CANL0, but the none of the ports seem to carry the CANH0 signal. Were there originally 2 controllers? I see a second choke but no second controller.

2 Likes

Thank you everyone! These are all very helpful thank you.

@VIPQualityPost
Thank you for the feedback! I am not sure why you would have issues with the layout file, except that I am using Kicad 7 now, I should have mentioned that.

Also thank you so much for reminding me to change the flash! In an early design review, our reviewer thought the other flash was too big, but now that I have used the board I would really like some space to dump rotating debug logs. I actually had a note to go back to a bigger flash and then forgot to change it, so that was very helpful!

And yes, the biggest feedback I got is that the schematic was a mess. I spent a good bit of time cleaning it up. I have not pushed the changes yet but it is much better now, with better names and clearer organization.

Pull down on the gate drive is a good idea, I will try to add those if I can find space.

For this board, cost is somewhat important but not so much that I wanted to dispense with the hardware CAN bus chip, though it is interesting to consider!

Our application does not currently use both cores but is is on my mind for sure.

@Anthony_Douglas
I forgot to mention, this board is designed specifically for our open source farming robot. An early version just used one CPU to control two motors, and then for ease of organizing software and to expand the GPIO, I added a second CPU to handle CAN bus communications and additional I/O. This makes it easier for us to produce another single CPU version in the future. And the point for us is to only have one board, to keep the cost of our assembly low. So this arrangement is somewhat specific to our needs, but we hope to produce a general purpose design with one CPU in the future once we know our drive layout is bullet proof.
As far as attaching a pico, actually since we already have to get the boards fully assembled, its simpler to just have it all integrated rather than have to attach a pico. But that might be a good solution for some folks!

@runger Yes that review on github is a huge help! Yeah the jumper for termination was a backup in case somehow can bus is not happy with termination through the DIP switch. I suppose it would be fine, but honestly I don’t exactly understand the considerations there.

Yes the two CPUs communicate via UART. CANH0 is on both ports, but I recongize that my schematic was a huge mess! That has been fixed now, though not yet pushed to github. The second CAN circuit is reserved for expansion via a connector on the board. So we could attach an additional CAN peripheral to the motor board and it would be tied in to the second CAN circuit coming over the RJ45 connector. That’s why it does not have a transceiver chip onboard.

2 Likes

Glad I could help! It seems like a really flexible design!

FWIW, I think that 128Mbit (W25Q128) is the largest the rp2040 can address.

1 Like

@Taylor_Alexander has published a new version of this board today.

It’s viewable here the files are here

If anyone had any design review of this latest version I’m sure they’d be interested.

This viewer is awesome!! Have never seen it before but it’s so silky smooth