YAFO- Yet another FOC controler

[GetItFix]

Dear All,

I would like first to thank all the members on this forum who shared their knowledge on FOC control design.
Finally, after investigation around MP2-ESC, Cheap FOcer, A200S, and other VESC-compatible HW, I have decided to design my ESC with the following constraints:

- Reliability/Robustness on top priority
- 14s Battery
- 50 Amps per phase
- TO 220 FET's
- Classic 8 pin drivers for each leg.
- Ease of DIY soldering AND servicing.
- No fine pitch components, except MCU (no choice !)
- Running VESC FW compiled with the appropriate parameters set
- Full compatibility with VESC tool
- 4 layer design PCB
- HAMMOND 1490WB Aluminum enclosure (106mm x 54mm pcb size)


So, here is the first draft of the schematic and any feed back will be welcome.

 

[hbozyq]

One thing I dont like is the D40. Maybe replace it with a <10 Ohm resistor, reduceing the peak voltage stress instead of keep the peak voltage.
And why you connect the snibber to +BATT instead of the Phase_x?

 

[GetItFix]

Thanks for this feedback

One thing I dont like is the D40. Maybe replace it with a <10 Ohm resistor, reduceing the peak voltage stress instead of keep the peak voltage.

I have used the same input circuitry which is used on the TeamTriforce A100S. (see picture)
Therefore, I think that I will keep the diode and will add a resistor of about 0.5 Ohms in serial with it.

And why you connect the snibber to +BATT instead of the Phase_x?

I do not plan to use snubbers on this 50 amp design, may be yes on a bigger one.
But you rise a good question:
I have seen snubbers between +BATT and phase_x (ie. CheapFocer 2) ...
...and I have also seen snubbers between +BATT and GND (ie. BESC Gen 2)
So, what is the optimal solution ?

 

[GetItFix]

Hi All,
Here is a small update of the schematic where I have added a 1R resistor before D40 diode, according to hbozyq suggestion.
I have also changed current shunt resistor from 0.4 to 0.33 milliOhms, allowing a current read of +/- 100 Amps
Then, last but not least, I have included in the schematic the following figure which shows some open hardware VESC-compatible projects on this forum. There is an exception with the A100S (commercial product) because I found the schematic on the net.
Please, feel free to make comments/corrections/updates if needed.


If the schematic doesn't show major errors, then i will start the pcb routing

 

[mxlemming]

This will work I think. Looks sensible for a simple controller. I'm always an advocate for hardware over current and also increasingly like gate drivers with enforced anti shoot through time. This is because I've seen some weird things on startup recently.

The canonical VESC hardware is the 75300. It's not the best in every way, but it and the VESC 6 and 100250 is the hardware Benjamin bases his development work on so if you want it to work well, keep your connections and filter constants similar to that.

Leave provision for parallel gate capacitance, and perhaps Diode resistor fast turn off. But don't populate them unless absolutely needed.

Consider fd6288q gate driver for 6 fet design. Save you space and has shoot through prevention and better voltage rating. The ucc part you listed is a bit hair trigger and allows shoot through and it's marginally rated for higher cell count application.

The numbers you've cited for the ESCs in that list are quite conservative. If people ran then at those powers they would probably last ages, but they don't. They get immediately jacked up to twice those numbers by most users.

 

[GetItFix]

Thanks mxlemming for your reply.

The ucc part you listed is a bit hair trigger and allows shoot through and it's marginally rated for higher cell count application.

Do you know others half bridge drivers preferably from TI, Infineon, Fairchild, ST and so on that could do the job ?
May be should I use a UCC27714 rated for 600 V but it will need an external bootstrap diode and gate pull down resistors.
In addition to this, this one has 14 pins instead of 8. And still no shoot-trough prevention.

I'm always an advocate for hardware over current and also increasingly like gate drivers with enforced anti shoot through time. This is because I've seen some weird things on startup recently.

Understood. Safety by hardware often better than SW. If I go for that, Il means that VESC firmware should take into consideration a special input on the MCU (similar to PB12 on your pill design) to reset all PWM outputs.
I did not found that option in the VESC source code.
Another alternative could use a driver with a ENABLE input connected to the output of current comparator.
Even with this 100% hardware solution, the MCU must be informed that "something went wrong" in order to take appropriate action.

The canonical VESC hardware is the 75300. It's not the best in every way, but it and the VESC 6 and 100250 is the hardware Benjamin bases his development work on so if you want it to work well, keep your connections and filter constants similar to that.

The 75300 has some kind of programmable filter with two possible choices 1k/1nF or 1K/15n. I have chosen a fixed one with 1k/1nF.
Do you think I should keep these values ?

 

[R4850S1_]

Do you know others half bridge drivers preferably from TI, Infineon, Fairchild, ST and so on that could do the job ?

I really like these gate drivers 2EDF7275KXUMA1

 

[GetItFix]

Thanks for this input. I am now routing the pcb and I need some advice regarding the use of vias on the gate circuit path.
First of all, my intention is to go for a 4 layer stack-up with Signal/Power - Ground - Ground- Signal/Power as explained here
The idea behind this is to leave the power traces outside with locally soldered copper strips.
I have also physically separated power ground and signal ground on front layer and connected them only in one point.
So here is the schematic portion showing the gate current path on the hi-side


Now, I have 2 possible options for the gate path. Here is the first alternative for the routing:


And the second alternative using two vias from front layer (red) to back layer (green)


So, any comment and suggestions will be welcome !

 

[mxlemming]

I really like these gate drivers 2EDF7275KXUMA1

This is a really good driver. I use them.

Thanks for this input. I am now routing the pcb and I need some advice regarding the use of vias on the gate circuit path.
First of all, my intention is to go for a 4 layer stack-up with Signal/Power - Ground - Ground- Signal/Power as explained here
The idea behind this is to leave the power traces outside with locally soldered copper strips.
I have also physically separated power ground and signal ground on front layer and connected them only in one point.
So here is the schematic portion showing the gate current path on the hi-side
View attachment 340436

Now, I have 2 possible options for the gate path. Here is the first alternative for the routing:
View attachment 340437

And the second alternative using two vias from front layer (red) to back layer (green)
View attachment 340438

So, any comment and suggestions will be welcome !

First one preferable. Kelvin connected.

Biggest issue lack of obvious decoupling capacitor.

Look at the mp2 /F405 pill repo, the pb12 code is in the hardware conf .c and .h

It's handled in hardware on the stm32... once the MCU has run the boot code, the timer has dedicated circuits to implement the brk. There's no MCU core involvement and it trips in less than 1 clock cycle.

 

[GetItFix]

First one preferable. Kelvin connected.

OK, mxlemming I followed your suggestion. Thanks for this valuable input.

Biggest issue lack of obvious decoupling capacitor.

I have put 5 x 2.2 uF 100V MLCC caps on the pcb backside, close to the FETs. (items C90 to C94)
May be 2.2 uF is not enough and should I change for more ?

Look at the mp2 /F405 pill repo, the pb12 code is in the hardware conf .c and .h

Yes.This give me some hardware improvement for the next version with external over-current protection, like you did with MP2
For the time being, this very first release look like this:


Now comes some DRC checking and then the boring tasks like components reference selecting and ordering...

 

[mxlemming]

2.2u is enough. Through hole FETs limit the surf you can switch and your bulk caps are close as well.

Your say you have physically separated the grounds except attachment at one point. How is this affecting your low side gate drive? Or have you made the classic mistake of assuming the signal between the MCU and gate driver can work fine with terrible ground connection?

 

[GetItFix]

Thanks for this positive questioning.

Your say you have physically separated the grounds except attachment at one point

Yes Sir. That was based on my previous job on single phase induction heater controls, based on IR2113 drivers. (230 VAC up to 7 kW)
I have followed 4 basic rules for power stage design I learned in the university:

1- Put drivers as close as possible to the MOSFETS​

2- Use two planes for power ground / signal ground, and connect them on a single point when dealing with high amps path.​

3- Add a tank cap AND a decoupling capacitor close to each driver VDD's . The "AND" is very important.​

4- Add one or two uninterrupted ground planes​

Of course, there are also others rules to follow, but these 4 ones became familiar for me.
So, here is the front planes with PWRGND and GND.
Connection between these planes are on the top left side through R0 resistor, which will be a solder bridge in the real world.

PWRGND Plane, front layer

GND Plane, front layer


For information, here the back layer showing the power trace +BATT , phase shunts and phase planes


GND plane, Inner layer 1.


GND plane, Inner layer 2

 

[GetItFix]

Hi All,
Got the pcb. Now time for manual soldering
Very fine tip, soldering flux and controlled temperature iron are mandatory.
Job will start by the inner/lower components and then going outside.

Surprisingly, the main difficulty was not the STM32 chip but the very small ferrite beads. I think I have reached my limits here.
STM32F405


Ferrite bead (really ugly, but cannot do more)


To be continued....

 

[mxlemming]

Probably a bit late now but when bringing up a board O always solder DCDC first then the consumers of power so I can test the voltage rails before putting the hours in to add the tricky stuff and expensive stuff. Too easy to wreck everything on a board with a converter error.

Your soldering looks better than mine tbh

 

[GetItFix]

Hi all,
Back to home and back on the project too !
PCB is now ready. 100 % hand soldered.
Started to test DC/DC conversion stage with a 0-60 Vdc current-limited lab power supply.
In the mean time, downloading and installation of VESC tool 6.02 on a linux laptop...




To be continued...

 

[GetItFix]

Following Testing OK:
At 60 Vdc I got a stable 3.3 V on the CPU.
I also write a very basic sketch to blink alternatively the green/red leds
Downloading the sketch using ST-Link working
Test program running OK with led blinking

 

[GetItFix]

Binary code ready with 2 customized files in /hwconf/other.
Other firmware code files left unchanged. Build firmware is 6.05
Flashing yafo_1450.bin using ST-Link.
Power off / Disconnect ST-Link / Connect usb cable / launch VESC tool / Power on board / click on connect in VESC menu
USB Communication between yafo board and VESC tool established


To be continued...

 

[GetItFix]

Got limited mode with VESC tool 6.02 and firmware 6.05. Still learning.
Downgrade to ground firmware ver 6.02
Recompile
Flash binary
Start FOC Autotune.
Got Happy



To be continued...

 

[GetItFix]

Hi All,
I have a tricky problem with displayed Amps vs real Amps:
Here are the test conditions:
Custom hardware/firmware using the above hw_yafo_1450 custom files.
FOC detection parameters done.
10 poles motor at no load running very well up to 60000 ERPM in FOC mode.
ADC Throttle as input.

14s battery and 1.20 A drawn from battery but more that 15 Amps displayed on the VESC tool !
About less that 2 amps really measured on motor phase using a current clamp multimeter.



Of course, I have double checked the INA240 Gain and shunt resistors (50 and 0.3 milliOhms here) in the above files.
Any input will be welcome !