Need help troubleshooting a burned MCP236.
Need help troubleshooting a burned MCP236.
I have a big robot I'm designing and building for work.
The setup is pretty typical: battery - MCPs - motors. With a host of additional electronics on the side, but which were not operational for the tests and are thus irrelevant.
I opened up the controller, found out that two of the MOSFETs (one side of one of the bridges) had failed with the typical drain-source short. This first time I thought it was due to the voltage spike (from the motor being stopped) exceeding the 100-V rating of the FETs, and (through reverse-transfer-coupling) destroying the gates, so I went ahead and installed the protective parts recommended in the manual. I hadn't done so at first due to being rushed to demonstrate the prototype by the company.
The only protective device I have not installed is a voltage clamp. Is it possible that the regenerative braking current is so high that the battery BMS cannot let it through ?? Granted, the battery is fully charged before every test...
I cannot think of any other reason the MCP burns, as while running, even for several seconds, at 8A motor current, it never even gets lukewarm. I have mounted each controller on a heatsing with a fan, seems to cool it enough.
Also, I replaced the two burned FETs on the older controller, since they had markings on them and I could read the part number (Infineon 070N10NS). However, on the new controller, the package has an exposed metal pad on top (presumably for better thermal conduction), so I can read nothing. What MOSFETs should I use to replace the two burned ones on the new MCP? Do they come in the metal-pad version, or is it custom-made for you?
On the old controller, after replacing the FETs, it works, but only the channel I repaired actually drives the motor. The other channel seems dead. Is it possible the FET driver is also burned out? I see no burn marks on the pcb around the part though. How could I diagnose the board? Use an oscilloscope to verify if the driver actually outputs PWM when switching? Are there othe test points I can check out?
In short: Help, plz...??
The setup is pretty typical: battery - MCPs - motors. With a host of additional electronics on the side, but which were not operational for the tests and are thus irrelevant.
- Each MCP236 drives a pair of PMDC servomotors (basically ordinary motors designed for servo applications, not actual servos).
- Each motor is rated for 48V and has a max continuous current of 10A, and a stall current (according to specs) of 48A. (L = 1.5 mH, armature resistance R_a = 0.8 Ω, terminals resistance R_t = 0.6 Ω)
- The battery is (currently) a Li-Ion battery with a nominal voltage of 48V (full 54.6V), and is fitted with a BMS. The BMS lists a max continuous discharge current of 30A, a peak discharge current of 90A, and a max continuous charge current of 5A.
- There are no encoders, so according to the manual, in open-loop PWM mode, with motor parameters provides, the controller should perform current control.
I opened up the controller, found out that two of the MOSFETs (one side of one of the bridges) had failed with the typical drain-source short. This first time I thought it was due to the voltage spike (from the motor being stopped) exceeding the 100-V rating of the FETs, and (through reverse-transfer-coupling) destroying the gates, so I went ahead and installed the protective parts recommended in the manual. I hadn't done so at first due to being rushed to demonstrate the prototype by the company.
- A 0.1 μF ceramic capacitor across the motor leads, and one across each lead and the casing.
- A bidirectional TVS diode across the motor leads (DigiKey part number: F7678CT-ND). Diode stands off up to 58V, begins breaking down at 64.4V, and clamps to a max of 93.6V, with a max current of 54A, so it should adequately protect the MOSFETs in the controller.
- A 1 KΩ precharge resistor with its own, dedicated switch parallel to the controller's fuse.
The only protective device I have not installed is a voltage clamp. Is it possible that the regenerative braking current is so high that the battery BMS cannot let it through ?? Granted, the battery is fully charged before every test...
I cannot think of any other reason the MCP burns, as while running, even for several seconds, at 8A motor current, it never even gets lukewarm. I have mounted each controller on a heatsing with a fan, seems to cool it enough.
Also, I replaced the two burned FETs on the older controller, since they had markings on them and I could read the part number (Infineon 070N10NS). However, on the new controller, the package has an exposed metal pad on top (presumably for better thermal conduction), so I can read nothing. What MOSFETs should I use to replace the two burned ones on the new MCP? Do they come in the metal-pad version, or is it custom-made for you?
On the old controller, after replacing the FETs, it works, but only the channel I repaired actually drives the motor. The other channel seems dead. Is it possible the FET driver is also burned out? I see no burn marks on the pcb around the part though. How could I diagnose the board? Use an oscilloscope to verify if the driver actually outputs PWM when switching? Are there othe test points I can check out?
In short: Help, plz...??
Go tell the Spartans, stranger passing by,
that here, obedient to their laws, we lie.
that here, obedient to their laws, we lie.
- Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Need help troubleshooting a burned MCP236.
Your BMS is preventing motor regen from going back into the battery which is causing a massive voltage spike in the MCP. Regen causes the voltage on the batteryt rise and the BMS is probably set to disconnect if the voltage rises farther than some point. If the batteries cant take the regen energy the voltage will rise beyond that point. I would say your BMS is too sensitive but if it is what you have your only option is to wire up a voltage clamp to deal with the regen energy under an all stop condition.
As for the damage, when a mosfet is damaged its about a 75% chance the driver chip will go with it. But first check if the gate resistor on the mosfet fused open instead. Sometimes those will protect the driver chip. If so replace the gate resistor and retest. Assume it still doesnt work then the driver chip will also need to be replaced.
The mosfets are tpw4r50.
As for the damage, when a mosfet is damaged its about a 75% chance the driver chip will go with it. But first check if the gate resistor on the mosfet fused open instead. Sometimes those will protect the driver chip. If so replace the gate resistor and retest. Assume it still doesnt work then the driver chip will also need to be replaced.
The mosfets are tpw4r50.
Re: Need help troubleshooting a burned MCP236.
I had figured as much, thank you for the confirmation. the BMS is indeed a "cutoff-on-overvoltage" one...Basicmicro Support wrote: ↑Thu Jan 16, 2020 11:04 am Your BMS is preventing motor regen from going back into the battery which is causing a massive voltage spike in the MCP. Regen causes the voltage on the batteryt rise and the BMS is probably set to disconnect if the voltage rises farther than some point. If the batteries cant take the regen energy the voltage will rise beyond that point. I would say your BMS is too sensitive but if it is what you have your only option is to wire up a voltage clamp to deal with the regen energy under an all stop condition.
So the gate resistors are the safety ("fuse-open") ones? I think I can find those locally (believe it or not, there is but ONE company in the whole of Athens that imports pretty much the whole range of electronic parts, and can also do custom orders.)Basicmicro Support wrote: ↑Thu Jan 16, 2020 11:04 am As for the damage, when a mosfet is damaged its about a 75% chance the driver chip will go with it. But first check if the gate resistor on the mosfet fused open instead. Sometimes those will protect the driver chip. If so replace the gate resistor and retest. Assume it still doesnt work then the driver chip will also need to be replaced.
Right, I will post back with results... Thank you!
Go tell the Spartans, stranger passing by,
that here, obedient to their laws, we lie.
that here, obedient to their laws, we lie.
- Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Need help troubleshooting a burned MCP236.
No. The gate resistors are just gate resistors(1/10th watt), though they are rated for high pulse energy. But any resistor will act like a fuse if enough power flows through them.
Re: Need help troubleshooting a burned MCP236.
Cool.
I checked the (omgsotiny!) resistors with the multimeter, without desoldering them.
I got a concise 6 Ω measurement across each one, so I guess the resistors are fine.
I also checked the pins of the MIC4102s (the gate drivers), but didn't get any short-circuit readings between the pins, not that that is any indication they work, ofc. I just couldn't quickly figure out which ones might be burned, is all.
Since I can power up the older of the two controllers (still waiting on the replacement MOSFETs for the newer one), I will attempt to check the PWM output of each gate pin using the oscilloscope.
I assume if I drive the controller "dry" (without any motors actually connected), there won't be a problem...?
I checked the (omgsotiny!) resistors with the multimeter, without desoldering them.
I got a concise 6 Ω measurement across each one, so I guess the resistors are fine.
I also checked the pins of the MIC4102s (the gate drivers), but didn't get any short-circuit readings between the pins, not that that is any indication they work, ofc. I just couldn't quickly figure out which ones might be burned, is all.
Since I can power up the older of the two controllers (still waiting on the replacement MOSFETs for the newer one), I will attempt to check the PWM output of each gate pin using the oscilloscope.
I assume if I drive the controller "dry" (without any motors actually connected), there won't be a problem...?
Go tell the Spartans, stranger passing by,
that here, obedient to their laws, we lie.
that here, obedient to their laws, we lie.
- Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Need help troubleshooting a burned MCP236.
Just be careful not to short any pins.
Yes you should be fine running the motor channel without any load. Try not to cause any more damage. If you think something is beyond you please just send the unit in and we will repair it. In most cases we don't charge anything and in cases where we do it is significantly less than retail.
Yes you should be fine running the motor channel without any load. Try not to cause any more damage. If you think something is beyond you please just send the unit in and we will repair it. In most cases we don't charge anything and in cases where we do it is significantly less than retail.
Re: Need help troubleshooting a burned MCP236.
Back again, with some results.
There was no shortage of pins I think (sry, couldn't resist the pun )
My experimental setup is as follows:
The first test is to move each channel slider (in the 'PWM settings' window) to a Duty of '100' (I assume it means 10%), and observe the gate signals.
In channel M2, without a load connected, the PWM at the MOSFET gates has a frequency of 2 KHz (500 μsec between pulse risings), with an "on" time of ~50-55 μsec - as expected. It looks like this on the oscilloscope (time = 50 μsec/DIV, value = 2 V/DIV)
However, in channel M1, with the test load connected, I get an "on" time of only ~20 μsec (~4%), with all other settings and slider position being equal.
Repeating the test with the load on channel M2 this time (I had to power down and restart the controller), I get OK waveforms on channel M1, and also OK waveforms on the side with the MOSFET I replaced (for the "forward" direction) of channel M2. For the other direction (the upper left FETs in the "replacements" image), I get the weird PWM output.
In addition, the "weird" PWM will not change no matter how high I move the slider. The "proper" one increases its pulse width accordingly.
Leaving the controller on idle for some time did not result in any change in behavior. I think the old MOSFETs may have all been damaged and are a (short) accident waiting to happen. What is your (remote) assessment?
My hands shake too much to attempt to test the μC's pins with the oscilloscope probe, I'd only short them together...
There was no shortage of pins I think (sry, couldn't resist the pun )
My experimental setup is as follows:
- 13.5V/3A max, regulated power supply. I opted for the low-range of acceptable supply voltage here.
- A 5.6 Ω resistive load for testing. That is a plain 5W power resistor, so it's a (more or less) strictly ohmic load, with negligible inductive or capacitative behavior.
- Studio general settings are: motor max current of +/- 1A, acceleration of 32768.
- Studio PWM settings are: L = 0, R = 5.6 for both motor channels, channels are not synced, acceleration for both channels set at 10,000 (looks nice on the oscilloscope )
The first test is to move each channel slider (in the 'PWM settings' window) to a Duty of '100' (I assume it means 10%), and observe the gate signals.
In channel M2, without a load connected, the PWM at the MOSFET gates has a frequency of 2 KHz (500 μsec between pulse risings), with an "on" time of ~50-55 μsec - as expected. It looks like this on the oscilloscope (time = 50 μsec/DIV, value = 2 V/DIV)
However, in channel M1, with the test load connected, I get an "on" time of only ~20 μsec (~4%), with all other settings and slider position being equal.
Repeating the test with the load on channel M2 this time (I had to power down and restart the controller), I get OK waveforms on channel M1, and also OK waveforms on the side with the MOSFET I replaced (for the "forward" direction) of channel M2. For the other direction (the upper left FETs in the "replacements" image), I get the weird PWM output.
In addition, the "weird" PWM will not change no matter how high I move the slider. The "proper" one increases its pulse width accordingly.
Leaving the controller on idle for some time did not result in any change in behavior. I think the old MOSFETs may have all been damaged and are a (short) accident waiting to happen. What is your (remote) assessment?
My hands shake too much to attempt to test the μC's pins with the oscilloscope probe, I'd only short them together...
Go tell the Spartans, stranger passing by,
that here, obedient to their laws, we lie.
that here, obedient to their laws, we lie.
Re: Need help troubleshooting a burned MCP236.
Believe me, everyone here in the company would love nothing more than to send the controller over to you, the most qualified experts to repair it, and save ourselves the hassle.
However, as I've mentioned, I live in Greece.
I will elaborate on why sending it over is a bad idea...
However, as I've mentioned, I live in Greece.
I will elaborate on why sending it over is a bad idea...
- Shipping the controller over to you is easy. The shipping costs would be approx. 20-30$.
- As soon as the package arrives to the US, you'd have to prove to your Customs that it is in fact your own product, returned to you, and not an imported item. Since you have the part number of the controllers you export, you'd be able to prove easily that this is in fact one of the controllers you exported to your UK reseller, active-robots.co.uk (which is where we purchased it from the first time). So no Customs duties for you - that you'd ofc roll over to us.
- Let's assume the best scenario: It takes you a mere hour to diagnose and repair the controller, so you decide not to charge us ( :love: ). Then, you repackage the controller and ship it back to us.
- Shipping stuff from the US to Greece has a higher shipping cost than from Greece to the US, since we are considered a less reliable destination (not unjustifiably I might add...). Therefore, shipping the controller to Greece would cost you about 30-40$ (which we'd have to pay, obviously, as is fair).
- The moment a package sent by a US corporate P.O. box arrives in Greece, it goes through Customs. This is where the fun begins. there is NO WAY for us to convince the authorities that we've already paid what is due for the controller. We do have the original invoice from active-robots.co.uk, but I doubt it includes the part number. Therefore, the Greek Customs authorities will assume we are importing the controller. This is their default attitude btw, since there is high traffic of ebay packages.
- The Customs duties include 24% of VAT. I do not have an actual duty tax percentage handy, but I believe it would be around 3-8%. I'll use a figure of 3%. Now the Customs authorities will need the controller's price. The simplest and easiest option is to provide them with the actual price of 220$ (anything else and we risk a hefty fine on top of everything else). That means 53$ of VAT and 7$ of duties for a total of 60$ at this point.
- In order for the package to be withheld, the customs will place it in paid storage, at one of the airport warehouses. To get it out of the warehouse, we'll be charged an extra 15€ (~16.5$) of handling costs. In fact, depending on how exactly the item was handled, we might be charged an extra 20€ (~22$) to retrieve the paperwork before the package can be processed by Customs.
- So far, the total is 125-167$, without you getting a single dime for your repair work. Now if you ship it back to our company address, we'll get a extra 100-€ fine, since companies need and EORI (Economic Operations Registration and Identification) number to import or export stuff outside the EU. We don't have one since we haven't had such a need so far. We can probably avoid that fine if I were to use my home address and personal credentials (so it would seem as if I'm getting the controller for my private hobbies or smth), but the Customs duties would apply still. Such a fine for the company would automatically make me fired and would probably put the company in trouble with the Greek IRS for quite some time. This is too great a risk, even if the other expenses were somehow more reasonable.
Go tell the Spartans, stranger passing by,
that here, obedient to their laws, we lie.
that here, obedient to their laws, we lie.
- Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Need help troubleshooting a burned MCP236.
Can you setup Skype with a video camera? I'd like to be able to work with you live on this.
Check your scope settings. You should have a period of 50us(eg 20khz). If it is anything other than that something is really wrong. Duty(high side pulse width) will depend on the duty setting.
Yes, if either L or R is NOT set it defaults to voltage control. Current control mode uses an algorithm that requires an inductive. Just to be safe I recommend setting both L and R back to 0.
You should remove the load. You dont need it yet. You will see a PWM output with or without a load. Retest and send me the results. Also the PWM aplitude should basically be battery +. If it is significantly lower than that then the mosfet isnt turning on all the way/correctly.
Check your scope settings. You should have a period of 50us(eg 20khz). If it is anything other than that something is really wrong. Duty(high side pulse width) will depend on the duty setting.
Yes, if either L or R is NOT set it defaults to voltage control. Current control mode uses an algorithm that requires an inductive. Just to be safe I recommend setting both L and R back to 0.
You should remove the load. You dont need it yet. You will see a PWM output with or without a load. Retest and send me the results. Also the PWM aplitude should basically be battery +. If it is significantly lower than that then the mosfet isnt turning on all the way/correctly.
Re: Need help troubleshooting a burned MCP236.
Thank you for offering to Skype. I will make arrangements and PM you (we are UTC+2, so I need to obtain clearance to stay in the lab until late, plus I'll need to find me an assistant if I have to manage probes and scope and the camera in real-time).
I will recheck the o-scope settings, since that "factor of 10" difference in the measured and expected frequencies sounds awfully suspicious of a "x10" button sneaking itself in there somewhere, but I'm pretty confident of my settings otherwise.
I will recheck the o-scope settings, since that "factor of 10" difference in the measured and expected frequencies sounds awfully suspicious of a "x10" button sneaking itself in there somewhere, but I'm pretty confident of my settings otherwise.
Go tell the Spartans, stranger passing by,
that here, obedient to their laws, we lie.
that here, obedient to their laws, we lie.