DRV8316 + ESP32 board

Hi, I’ve started on my next board build.

This is using:

  • DRV8316 (engineering sample)
  • ESP32 PICO V3
  • MA702 Encoder

Here’s the KiCad render:

And the board in real life:

The idea is that the magnet would be glued to the end of the motor shaft, and the driver board would be attached to the motor - with washers or a 3d printed spacer.

I have one issue so far with how I’ve setup the DRV’s sleep pin, but I can work around this for testing.

This is a 2 layer board, and this time I’ve used HASL instead of ENIG, and it worked well.
Total BOM cost in quantities of 10 is around $13.

Now I’ll have to look at @runger 's code to get SimpleFOC running!


I love it! It looks really nice too!

May I pester you with a few questions?

  • Am I right that you’re not using the WiFi on the ESP? I can’t see any antenna…
  • What voltage can it support? Did you get it with 2Oz copper or more?
  • Did you reflow it yourself or order it with assembly?
  • It it intended to be mounted facing the motor, or can the MA702 sense the magnet through the PCB?
  • What’s your bulk capacitance? Is it C17-C22? How much does that amount to?

I have a DRV8316 based design in production (I’ll post here as soon as it arrives, but it will be a few more weeks unfortunately!)

In terms of the driver code it is working well for me for 3-PWM and 6-PWM… if I know someone is using it I shall prioritise adding the other features like current sensing and fault management…
I’m also going to split it off into a separate repo.

I’ll send you an update once I have it done.


  • Correct - I’m not using WiFi/BT, I don’t have the power overhead to enable them, or the matching antenna network for it.
  • The VM caps are rated to 25v, so the max would be a bit below this. I’m just using 1oz copper for prototyping - I’ll see how it goes.
  • I reflowed it myself with solder paste, stencil + hot air gun. I’ll probably make a video of it when I make the next revision.
  • It would be mounted facing the motor. The connectors could be flipped for motors larger than about 46mm dia.
  • Yes, C17-22 are my bulk capacitance - 6 x 22uF. If it’s not enough - I’ll probably have an electrolytic off-board.

Thanks for your work on the driver - I think it’s going to be fun playing with all the features!

I’ve got closed loop angle control working with 6pwm!

I’m linking in the driver in platformio.ini like this:

lib_deps =

With this 0.067 ohm motor, it really heats up fast where the thermal vias are!

I have a split ground plane for digital/power. Maybe I should put a net tie in right near the pad - to let some heat across?


I would expect it to get hot when driving near its current limits - are you running open-loop or closed-loop? If there is no load on the motor, there should be a big difference between FOC (closed-loop) control and open-loop control in terms of the current drawn - which will help keep the driver cool!

Other than that, I’d expect you probably need a heat-sink when driving 2+ A continuously.

Also, it depends how hot things are getting - if its 70° or 80°C that does feel hot to touch, but should not be an issue for a motor driver IC. If it goes above 100°, id be concerned, but it has OT protection so you should be fine either way.

I don’t think a net-tie will help much - what you want is a large copper area around the chip, which you do have… maybe 2Oz copper would help a bit, and leaving the copper exposed, but in the end there’s only so much heat you can dissipate though thermal vias into a PCB… heat sinks (and fans) are pretty much a must on ESCs that handle multiple Amps… on Quadcopters these are never present because the quads are “self-cooling” when they fly… but on RC-cars the performance ESCs always have heat-sinks, and many have fans…

This is running closed loop. It’s cool when idle, or free running - and only heats up under heavy load.
Yes - it’s just hot to touch it, not too bad. I’m sure it’s ok at that temperature.

I’ve started design of my revision 2.

My problem is with the DRV8316’s nSLEEP. It requires a logic high, and the internal LDO and Buck won’t start up without it being driven high first. (Chicken and Egg…)

I had the MCU setup to use the DRV8316’s buck - with a small external LDO. It works fine, and reduces my component count and cost, but I can’t drive nSLEEP high…

Now instead, I will power the MCU by it’s own buck, which can also drive the nSLEEP high.

I’ve seen these sleep low things before and they are quite annoying! If you know your source supply voltage you could use a voltage divider. nsleep max = 5.7V - I suspect it’ll be on between 2.5 to 5.5V which gives you a fair bit to play with i.e you could choose resistor that work between 12-24V.

Thanks - Yes, it has a pretty wide range of 1.6 - 5.5v. I was thinking of using a voltage divider, or a zener voltage clamp. With a divider, I could get 7 - 24v input range.

But I figured that by the time I add these extra parts, I could combine them with the LDO I had powering the ESP32/Encoder/CAN, and swap it for a buck (+ 1 or 2 more parts).

The LDO was required between the DRV’s Buck and these components - because the DRV buck voltage can be increased to 5.7v with a register write, and 5.7v would fry the esp32, and be close to absolute maximum for the other two.

If only they had made SLEEP a pull down to enable pin, or given it the full range of VM. It would made the integrated buck/ldo so much more useful.

Perhaps @xcalplaxis can explain why TI went with enable high on sleep high on the sleep pin. I can understand it on other drivers but on this device with a buck, it does lead to that ‘chicken and egg’ situation where the mcu powered by the buck can’t enable the drv8316 through its nsleep pin.

Believe it or not it is for safety reasons. Better to have the driver shut down when there is no voltage present in the system. There’s a relatively simple circuit you can use to turn on the nSLEEP via a switch from VM, and then once the MCU is awake hold on nSLEEP.

We have other parts where the regulator is completely independent (i.e. DRV8323R), but on this one the regulator is very much tied to the power up sequence of the DRV.

By the way, the 5.7V setting on the regulator is intended for situations where you would want to put an LDO outside our part to generate a cleaner 5V rail. It gives some headroom for that external LDO.


Hey, just to let you know I moved the DRV8316 code to a better place:

Development will continue there. Let me know if that works for you. The functionality is the same for the moment, it just got moved into its own drivers library.

1 Like

Thank you, I’ve switched over to this repository, and it works great.

My “platformio.ini” now looks like this:

platform = espressif32
board = pico32
framework = arduino
lib_deps = 
    Simple FOC drivers = https://github.com/simplefoc/Ardunio-FOC-drivers.git
monitor_speed = 115200
build_flags = 

I deleted the cached libraries, and it downloaded the Simple FOC dependency correctly.

My revision 0.2 board is here. With the external 3.3v buck - it works like a charm!

Here’s a shot of my solder paste job:

You can see on the DRV8316 that I was about 1/3 of the way off the pads - but it still reflowed nicely.


Hi Jason, I was able to finally order some DRV8316 chips and am planning on making a similar ESP32-based motor controller. Are your kicad designs for your driver publicly available? I’d love to take a look. Any updates to v0.2? Thanks!

Ah just saw your update thanks DRV8316 mini controller - #12 by Valentine. Any updates to that design?

Hi Nate,
I’ve pushed the latest changes to the Git repo: GitHub - jkirsons/stealth-controller-mini: Stealth Controller Mini
(just minor changes I think)

1 Like