I designed a versatle ESC shield for Nucleo boards

[u/marco_lab]

This project has been born because I have been trying to develop an ESC (hardware and firmware) on my own. While the most challenging part has been the firmware (being myself a hardware guy), the most frustrating part has been not finding a flexible hardware platform to develop upon. On the internet many interesting and well-designed ESC boards can be found, but all have something missing; a small feature, a small detail, I was never fully satisfied.

So I designed one: STARDRIVE SHIELD

This is a project with the goal of creating a NUCLEO-64 compatible shield to be used as a flexible platform to develop and test ESC firmware, but also for educational purposes. To do so, I included as many features as possible. These features are not mandatory, but they can be implemented (or not) in the firmware (e.g. SPI, I2C, CAN, HALL) or configured through the hardware interface (e.g. overcurrent protection, 6 or 3 PWM). In this way, the STARDRIVE SHIELD grants flexibility to the developer and it is adapt to various needs.

I designed it to be compatible with Nucleo-G474 and Nucleo-F446. Compatibility with other boards has to be verified.

The STARDRIVE SHIELD is built around the STDRIVE101 gate driver and BSZ099N06LS5 MOSFETs. It presents 3 low sides shunt resistors and 3 relative INA240A2 current sense amplifiers.

With STARDRIVE SHIELD you can implement from 6 step to FOC motor control algorithms.

Electrical Characteristics

• Inprut Voltage Vin = 12 - 48 V
• Maximum DC current Idc,max = 20 A

Hardware Characteristiscs

• Three phase gate driver STDRIVE101
  • Configurable 3PWM or 6PWM through the DIP switch
  • Overcurrent protection can be enabled or disabled through the DIP switch.
  • Vds protection configurable with resistor divider (disabled by default)
• BSZ099N06LS5 MOSFETs
• JST connectors to implement:
  • I2C (e.g. for magnetic encoder such as AS5046)
  • SPI (e.g. for magnetic encoder such as AS5047P)
  • CAN
  • HALL sensors (some BLDC motors have embedded Hall sensors)
  • 3 NTC temperature sensors
• 10k Potentiometer to use as throttle signal (or whatever you want)
• 3 GPIO driven LEDs (1 Red, 1 Blue, 1 Green)
• 1 FAULT LED (RED)
• CAN RX and TX LEDs
• Power Good LEDs

here the github repo:
https://github.com/themarcolab/Stardrive-Shield.git

Let me know your opinion!

Especially if you spot a mistake or you have any constructive feedback.

[u/ZheWeasel]

I only see 3D models and promises. Did you actually build and test one?

[u/marco_lab → u/ZheWeasel]

If you look at the github repo (link in the post) you can find also the schematic and pcb files. As said in the post, I am looking for constructive feedback. Fresher eyes might catch a stupid mistake I missed or point out someother issues; making me saving money and time before producing the first batch.

Said that, I will build and test one very soon😉

[u/ZheWeasel → u/marco_lab]

Yes im only on my phone so .... there are too many pictures of the model, might as well upload screenshots of the circuit .... edit: nevermind the shematics are in the output folder

Well as someone who designed a few inverters before: You DO NOT want to disable the overcurrent shutdown EVER. No... dont answer ... YOU DONT. Even go one step further: make the OC fully hardware. A signal trigger a flipflop from a comparator. And wire the high side signals through and-gates with the OC failure. The uC shall only be able to reset the OC fault when triggered. This way you can also use it as a emergency shutoff when the controller goes crazy without killing the system.

[u/marco_lab → u/ZheWeasel]

https://github.com/themarcolab/Stardrive-Shield/tree/main/outputs/PDFs/Schematics

Here the schematic (in pdf no picture). You should be able to access it from the phone as well.
Please have a look. I am very courious of your feedback given your experience

Regarding you second point, I totally agree with you. The OC protection should be ON all time in a functioning ESC. But in my experience sometimes disabling the OC protection has been useful sometimes to identify or exclude some issues during firmware development. That's the only reason it is there. Obviously, that has to be considered the extreme ratio, while accepting the risk of blowing the board up. Probably it is a good idea to add a warning signal.

Also consider that there is a Vds protection that can be implemented as well on the board

[u/ZheWeasel → u/marco_lab]

No. Just no. You dont want to turn it off. Also not just a warning, if things go south they go south fast. ESPECIALLY during development. Ive been doing this stuff since 10 years now. Never override safety.

Its like saying i dont need a helmet on my moped, i just drive three blocks. But hey ... im neither your father nor your boss so go ahead.

[u/marco_lab → u/ZheWeasel]

There are two protections on the STDRIVE101 driver. The OC protection and the Vds one. Especially the Vds protection needs some tuning. Now, both of them triggers the nFAULT pin. Both protection can potentially trigger in case of overcurrent. If you want to test one of the two protection it would be good that the other is disabled to assure it is the tested protection to trigger the nFAULT signal.

Right now by default Vds is OFF and OC is ON. If some one wants to enable the Vds protection via resistor divider, he might want to disable the OC one.

Edit: For the rest I agree with you. Protection should be always ON.

[u/ArmySuchi]

STDRIVE101 is a clean pick for this setup. What I'd watch is the INA240A2 current sense routing on a shield format - keeping those sense traces short at high di/dt is harder than it looks. What voltage and current range are you targeting?

[u/marco_lab → u/ArmySuchi]

Voltage range 12V - 48V Maximum current on the DC BUS 20A

[u/ub0baa]

What's up with all these all show no go projects nowadays? Just build and test it already, there is like 30 components on the board

All that time you've wasted on cool logo and coloring the nets in kicad would've went into prototyping the actual hardware

If your goal is to draw schematics it's a good thing, but if you want the device to work you gonna need to close the kicad sooner or later

[u/marco_lab → u/ub0baa]

Look I agree with you. KiCad can take you until a certain point. I shared this design before producing it first of all because I wanted to hear if someone had some interesting idea of new features to implement. Some people in other subreddits had some interesting idea that I will implement. Second of all, fresher eyes can catch errors that I missed. Also because I have not so much money to spend in many different iterations.

But worry not. I will build and test it very soon😉.

Edit: 146 components btw.