preventing mosfet burns..

[RoboDurden]

Successfully replaced two mosfets today :-/ Would be great for this firmware if it could be made safer (than other firmwares ?)

1. lose current phase cables: I learned (the hard way) that lose connections of one of the three phase current cables will make it more likely for the mosfets to burn ! Disconnecting hall cables do not seem to be a problem(?) I think the firmware could detect this if the current could be monitored at the same speed that the mosfet apply their pwm to different phases. So when the two mosfet of Phase A allow the most current but the measured current is less then "predicted", the board could/should shut down. The period of lesser current would identify which phase has a loose connection.

2. softer start/stop A few times already a mosfet bridge burned right at the beginning (and once at stop?), and there was not even any load/torque on the motor ! This time i reduced the DEFAULT_FILTER from 0.1 to 0.01 = 655. Such a slow start/stop is okay form my two circular saws on my log band saw: https://www.youtube.com/watch?v=sveUO8Rd1TQ But i feel that the start/stop could be somehow(?) made safer even for fast start/stop.

3. a safety help page ? Is there a wiki page on what other measures could be taken to prolong mosfet lives ?

4. hardware changes ? Does anyone had any success with hardware modifications ? Adding a protecting diode might interfere with the charge pump of the high-side mosfet :-/ Replacing the mosfets with better ones ? Simply soldering seconds mosfets on bottom of the existing ones might be easier!

Ideas welcome :-)

[Candas1]

Hi,

You seem to say that it's not happening with other firmwares ? 1) It happened to me also that a phase got disconnected. I am not sure it's easy to detect, need to think about it. 2) I am not sure why this would happen. One idea that I have is that if one gate driver or mosfet is shorted, the firmware turns the other mosfet ON and is too slow to detect the overcurrent. I am thinking about running a diagnostic at startup, but it will take me some time to implement this. 3) No, so far I have been writing about identifying issues, not preventing it. And the more I write and the less people read it. 4) I have no idea about that.

I captured here some of my learnings and possible improvements, I will try implementing this winter if I find enough time.

[RoboDurden]

I only use your FOC firmware so i simply assume that no firmware has better protection and you might want to make your firmware even better with additional mosfet protections..

1. lose phase cables: Thanks for the .doc link, i have read the two "old discussions" to learn that hardware already does phase current measuremnt by using the R_DS_on as a shunt resistior (i did the same for my pocket spot welder :-) ) The shematics says that all three phases have opamps outputing to MCU adc inputs and maybe only two phase currents are actually evaluated because of timing issues.. Such a phase current ends up here: https://github.com/EFeru/hoverboard-firmware-hack-FOC/blob/24b3d2515f70c0709b658364930930a935e6552c/Src/bldc.c#L185 and only seems to be used to calculate the "saturation" in https://github.com/EFeru/hoverboard-firmware-hack-FOC/blob/24b3d2515f70c0709b658364930930a935e6552c/Src/BLDC_controller.c#L1271

If such a current value is logged and the corresponding phase cable pulled, it should be easy to find a protection rule like you already have for a hall cable being pulled (board starts beeping when hall connector gets pulled ?)

Maybe you have to compare the two phase currents of one motor and go into error mode when they do no longer "somehow" match.

(When replacing two mosfes i harvest these from another broken board. But different mosfets will have different R_GS_on and now my phase currents are wrong. So it seems to me that only same mosfet should be considered for a replacment.)

I do not know why a lose phase cable can kill the corresponding two mosfets but from my experience this is the case. So i would like to have such a protection feature. Next year when i am back to run my log band saw i will try to log these rtU_Left.i_phaAB etc. and see if i can find a fault detection rule.

2. softer start/stop: startup-checks are not that helpful, because the initial damage for sure happens when the board is running. I simply experienced a mosfet bridge to blow with an abrupt start or stop, no matter of the load on the motor. But yes i have read in those old discussions that you try to get the most out of the motors and that might increase the risk of the highside mosfet not yet fully being off when the lowside mosfets already opens - leading to a shortcut that would/could blow the two mosfests. Again, logging the phase currents might give some insight. This time at start and stop. As i said, the load on the motor is not the problem (load on the motor would of course result in high currents at start).

I have not fully understand that voltage pump used to generate the +14V for the highside mosfets. It seems to be generated automatically with the pwm on the two gates (low side off => capacitor charges, low side on => capacitor fills high-side-gate-voltage-capactior ?). Making the gate pwm more complex due to a FOC algorithm might create nasty voltages for the highside gate driver ?

These are just some suggestions and i am no motor expert at all. But such an expert might immediately see where a possible software protection could be added.

roland, little physicist :-)