ESP32 Brushless controller - Dagor

Hey guys,

I’ve been working hard on my new board based on the ESP32 and the DRV8305. The ESP32 will make the board have some interesting connectivity options and ESP-NOW seems to be a great option for wireless communication. My idea is to make this board very capable for it’s size and very affordable; the board and code will be fully open-source. These are the key specs of the board:

  • 5-24V
  • 40A peak current
  • Current feedback with 0.002 ohm resistors
  • 3.3V Buck converter
  • 44x44 mm
  • 4 layer PCB with thermal vias

In the Hackaday page of the project I post regular updates:


I’ve made a few tests where the board worked completely but it hasn’t been reliable and I’ve been having some issues that I can’t seem to resolve. It’s my time to ask for your help.

Issues I’ve fixed:

  • I made a mistake with one of the feedback resistors of the buck converter. I managed to desolder the 0402 resistor a make a small bridge to the correct pin (this is already fixed on the schematic). Also removing resistor R11 and bridging the pin to PVDD helps with the chip’s enable. I’m considering changing the converter for the AP63203, it is 3V3 fixed, uses less passive components and I’ve had a good experience with it in another design

  • Removed capacitor C31 to ensure that the ESP32 goes to boot mode on power on. This small capacitor was adding a bit of delay on the pull-up of the IO0 and this made the ESP32 go to flashmode on power on.

  • It’s very easy to kill an ESP32 just by touching the buck converter, so avoid doing this. Most of the rest of the tests I’m not powering the ESP32 from the buck converter, instead I’m using an external 3V3 source and the results seem exactly the same whichever way I power the microcontroller. I’m doing this by opening the solder jumper SJ1.

Issues I haven’t fixed (ordered from most important to not so relevant):

  • IO0 seems to get affected by IO4. IO4 is used as an input for the fault notification of the DRV8305. When the driver detects a warning it will pull-low the pin periodically (thus creating a square wave) and when the driver detects a fault it will pull-low the pin and hold it until it gets a reset on the enable pin. With my scope I noticed that the signal on the IO4 is affecting the neighbor pin, IO0. My first thought was a short and I confirmed the short with my multimeter though I couldn’t see it physically. I added a bit of solder and removed it and the short was gone but the behavior wasn’t. I have had this happen with three different boards and the short between IO0 and IO4 seem to randomly come back and if I repeat the procedure of adding and removing solder the short will go away. I noticed that I should have added a pull-up resistor to IO0 because I read the internal pull-up sometimes is too weak, but this seems to make matters worse. Here’s what my scope shows, red IO4, yellow IO0:

IO0 and IO4

  • This random type of short has happened also with TXD0 and RXD0. Where they go away when I add and remove solder, are not physically visible and appear back randomly. For these pins and IO0 and IO4 I placed the vias like this:

Do you think this might cause problems? I really don’t think so.

  • The status of the En pin and IO0 seem random when powering. Sometimes when I power on the device the pull-ups will be ok, and sometimes they will be too weak.

  • SPI communication with the AS5147P encoder seem to work sometimes and sometimes not. I’ve gotten a few shots with my usb scope. I will post these later as I think the issues above are more important.

Really impressive work :ok_hand:

Regarding the boot status of ESP32 I do remember that a few pins are difficult to use.
Some pins are outputting PWM signal and thus can’t be used properly as input during boot time.
I suppose that you are well aware of this.


1 Like

@freedom2000 Thank you :slight_smile:

Yes, I made sure I knew what pin I was using for what. For example I know IO2 has to be pulled low to be able to put the ESP32 on flash-mode. This IO has an internal pull-down that takes care of this and I’ve connected it to the enable of the DRV8305 which also has an internal pull-down so the state of this pin has never been an issue.

I took this page as a reference of the GPIOs:

This page for the bootstrap pins:

The board is looking good, I hope you resolve your shorting problems. Not really my area of expertise. I take it you think it’s above the solder mask? Seems to be plenty of spaces between your copper lines. I suppose if it was under the mask you’d spot it on your spare (non soldered) boards.

Could the short be solder that has got under the main body of the esp? Maybe using solder paste or loads of flux would stop this happening?!? The fact that it has happened a few different boards might mean that there is something about the design that is making it difficult to solder e.g. the esp32 pads need to be a little further apart/out.

Perhaps the short is further away from the esp pins???

Good luck btw!

Great !
I have exactly the same reference pages !

@Owen_Williams I have some boards with no components and those boards show no problems with shorts, so I that would discard a manufacturing problem.

I got 5 boards with no components and 5 boards with all the components minus the ESP32, the AS5147P, the buttons and the inductor (as seen in the picture with the coin).

My guess is that something is happening under the ESP32 and I can’t see it. My soldering skills are not the best, but I always make sure there are no shorts and clean everything with alcohol. I’m considering a short something that shows <100 ohms on the multimeter, a pin with no short will usually show a resistance of around 100kohm or even megaohms with any other pin. With 3 of my boards and five different ESP32s I’ve had these shorts that are not visible and that type of weird - inconsistent behavior. I just realized that these shorts have happened on other pins between neighbor pins on the ESP32. I believe this has been the root of all my problems, bad bootstrap pin status, bad SPI communication, bad communication with PC, etc.

Would anybody have a recommendation to avoid this? I’m open to skype if somebody wants to chat :slight_smile:

My colleague said (he is responsible for the hardware circuit), your PCB layout is too compact, this layout can only be overcome by a real top EMC / EMI master!

His suggestion is to abandon the “5047” on board and rearrange the PCB with the free space.

I have a very similar board and here are my thoughts.
The GND pad on your board under the ESP-32 WROOM looks too big. Mine is 3.5x3.5mm
My pads are 1.45x0.86mm

ESP-32 IO12 needs a pull down
I had to use a 100 Ohms resistor between ESP-32 SPI-CLK and the AS5147
I didn’t use flux when soldering on the ESP-32 WROOM.
I used as little heat as possible. I didn’t want to melt the solder on the inside of the Module.
I soldered all the components by hand (your board is a lot cleaner)
Did you get your ESP-32 WROOM board from Mouser?
I hope this helps

@Gouldpa Thank you for your comments.

You’re right my GND pad is too big, I was considering getting rid of it altogether as it’s not a requirement and I never solder it. My pads are 2x0.72mm

I’ve monitored the state of IO12 and it’s pulled down always as I don’t use this pin. I’ve added an external pull-down with no different behavior.

What’s the reason behind not using flux? I was starting to think that maybe I’m doing something horribly wrong with my soldering and this is the reason I’m having so many problems.

I got my ESP32 from LSCS electronics, I got ESP32 WROOM 32D and 32U.

Flux could be getting inside the metal can and/or too much heat could cause problems inside the can. Your 32U looks different from mine but LSCS is a reputable company so it will not be a fake module. I also put a layer of silkscreen under the WROOM module to make sure there weren’t any shorts.

After further testing I’ve concluded that all my issues have been because of the ESP32 wroom module assembly. Every time I notice the board behaving strangely I’ll find with a multimeter a set of neighbor pins on the ESP32 that seem shorted when they were previously not.

For example, one time communication seemed to stop working so I grabbed my multimeter and found TX0 and RX0 shorted after days of having worked properly.

I fixed the short just by touching the pins with a hot soldering iron and the short will go away for a few days or hours.

The shorts always seem to come back when I’m using the board. If I leave it unused for a few days no short will appear. I’ve been reading online and I think I have some sort of contamination on my board that will produce dendrites or something similar when operating. This could have been cause because of bad quality solder, flux or alcohol.

Would you guys please recommend me brands for all of the above that you have tested and have gotten good results in the past? Thank you.

@Gouldpa I’ll definitely keep your recommendations in mind when assembling another board, thank you.

1 Like

Demo video of the board and ESP-NOW communication.


Awesome! Whats the rating on the switches and what copper thickness are you using?

Excellent progress!

What is the status of your dagor board? Have you fixed most of the issues? Were they soldering problems? Is it possible to build / buy one of these yet?

How hard was the espnow coding?

All the issues were because of the soldering. Given there are no visible shorts I still have problems with shorts that will randomly appear on some pins and I’ll notice because the board will start to behave weirdly. I’ll say the issue is totally resolved once I assemble a board and have no problems. I’m thinking on changing everything: solder, flux, soldering iron tip, solder wick and try with a new board to see if that does the trick.

Not yet, I’m thinking on doing a few improvements, like changing the buck converter - but I haven’t decided.

So so so easy, it’s quite surprising how easy it is to get working. With the motor.command() function that @Antun_Skuric implemented I just have to send and read a String.

1 Like


I like what I am seeing, I have a few questions and suggestions.

Why did you choose to put the encode on the board? I think that applications off this board will often have the need of an external encode like the AS5600 (I²C), maybe make it so you can choose?

Why did you choose the ESP32 as the microcontroller?

I look forward to hearing back from you :wink:

Carelsbergh Stijn

I put the encoder on the board because it’s intended to be small and close to the motor so I can make a compact actuator. If you look at the back of the board you can see I left some pins for an external SPI bus or an i2c bus.

Because of it’s connectivity options, community and arduino compatibility; though it’s been a challenge to use. I’m looking forward to use ESP-NOW for a lot of my proyects and I just like the idea of having no wires. You can check out an ESP-NOW demo above.

1 Like


There is no need to ignore the copper thickness. If you are using standard pooling thickness for prototypes and plan on maybe 105um, you may be able to achieve half the switches rating. The heat is the limiting factor, and if your traces cant cope with the current flow, it will heat up your components and thereby add to the Rds(on). What is your trace width and copper thickness going to the MOSFETS. To use 105um copper there is a minimum 0.25mm trace width and likewise clearance.

Edit: As you may know, internal layers is quite poor at dissipating heat, therefore it is misleading to just write “its a 4 layer pcb”. I think the ground trace must be equally wide/thick.

Best regards

Nice compact design. Specially ESPNow control is nice feature.


1 Like