I have a 3 phase inverter H bridge which has 6 MOSFETs (IPD90N04S4_05) as shown in the picture.

3 phase inverter H bridge with 6 MOSFETs

I have numbered each leg of a MOSFET as 1, 2, 3, 4. The middle leg (number 2) of the MOSFET has been cut and pushed down.

I have found the data sheet:


How can I find out whether MOSFETs are OK or not?

My second question start here.

I use these MOSFETs with an Infineon chip and my programing environment is Keil Microvision 5.

Earlier I was able to operate the MOSFETs using PWM from the Infineon chip for a BLDC motor application. But all of a sudden , one day when I supply PWM pulses to the gates of the MOSFETs, the error I get (from the debug window of Keil, screenshot below) that "external FET source–drain short" for all 6 MOSFETs.

But surprisingly when I check physically with multi-meter the source and drain (leg no 2 and 3) don't show any short.

How is it possible?

(In this picture two MOSFETs are shown as HS2_DS_STS & HS1_DS_STS as 1(short). Similarly remaining four MOSFETs also show Drain-Source status(xx_DS_STS=1) short).

  • 4
    \$\begingroup\$ which is your question? ... the title of your post or the last sentence? \$\endgroup\$ – jsotola Dec 17 '17 at 1:55
  • 3
    \$\begingroup\$ you can do all the numbering that you want, but it is pretty useless when there is no schematic to refer to. \$\endgroup\$ – jsotola Dec 17 '17 at 1:59
  • 3
    \$\begingroup\$ Is this a board you designed / made? \$\endgroup\$ – Tyler Dec 17 '17 at 2:31
  • \$\begingroup\$ The specific device was not mentioned in the question, but it seems that you are using a member of the Infineon TLE987x family (3-phase bridge driver with ARM Cortex-M3 core). It is the registers from that device, which you are displaying in the screenshots in your question. Therefore it is that device, which is deciding to report (in that register) that the MOSFETs are shorted. It will probably help if you supply links to the manuals for that device, so readers can see how the manufacturer explains the decision-making that causes it to set that status bit. \$\endgroup\$ – SamGibson Dec 17 '17 at 2:59
  • \$\begingroup\$ Thank you all.I am using Infineon "TLE987x Eval Kit" for BLDC application.My program environment is Keil microvision 5.infineon.com/cms/en/product/power/motor-control-ics/… \$\endgroup\$ – litun bls Dec 17 '17 at 3:04

I have been stuck with this problem for last one month unable to figure out whether it is a software problem or hardware problem.

I don't have your hardware in front of me. However, based on the information you have given, and my own research, I'll give you my hypothesis. I would start by suspecting software, not a genuine hardware fault, for the following reasons:

  • a) If the interpretation of a FET source-drain short was valid, as per your interpretation, for all 6 MOSFETs, then you would have needed to damage them all, at the same time.

    Damaging 6 Power MOSFETs so that they are shorted would, in my experience, usually have been obvious (noise, smell, smoke, damage to the device package etc.).

  • b) The chances of all 6 Power MOSFETs being damaged (as per your interpretation) is not very likely (if it was just one or two damaged devices being reported, that would be different).

  • c) As you have said, you can't actually measure a source-drain short, again suggesting that this is a false report.

  • d) In your question's title, you asked for the reason for "MOSFET over current". However the status bits which are set at that point in your code, are not for overcurrent. Notice that the status bits which are set in register CTRL1, are the HSx_DS_STS bits not the HSx_OC_STS bits, so the detection mechanism is different. It seems that you are trying to perform a Bridge Driver "Off-Diagnosis".

  • e) Possible error in the TLE987xQX User Manual linked from this page.

    In section ("Preparation") notice how figures 218+219 and 221+222 are identical, yet the text before each of those saying which bits should be set in each figure, are not identical. Therefore either the figures or the text are wrong, IMHO. I suspect figures 218+219 are wrong, as the text does not match those.

    Step A in that Bridge Driver "Off-Diagnosis" procedure says:

    A: All phases must be switched in "Enabled"-state (but not "ON"-state)

    However figures 218+219 (wrongly?) highlight the DCS_EN bits not the EN bits in the CTRL1 and CTRL2 registers! So the figures do not match the text.

    After step A, you have to do step B, involving writing to CTRL3. Then the DCS_EN bits should be set later, in step C:

    C: Enable Drain-Source Current Sources on the High-Side (HSx) drivers

    And only after that, you perform step D, clear the DS_STS flags, and check whether they remain clear:

    D: Assuming the motor contacts do not have a short to VBAT or to GND, all the DS-Status flags of each phase can be cleared now, and shall stay cleared.

    Therefore I suspect you are being misled about the correct software procedure, due to the contents of figures 218+219 which suggest you set the DCS_EN bits at step A (which we can see you doing, where you write 0x09090909 to CTRL1, for example). However the User Manual says those bits are set at step C.

  • f) There is the possibility of a motor problem, causing all HSx_DS_STS or all LSx_DS_STS bits to be set, as explained in section (Detection).

    However since you are reporting all HSx_DS_STS and all LSx_DS_STS bits to be set, then this possibility doesn't make sense. You could investigate running the same test with the motor disconnected. Obviously the "open load" would be reported, but if the DS_STS bits are still set, then a disconnected motor can't cause that!

  • g) I had a quick look at some sample code from the Infineon site, but (i) I couldn't see any sample code which included that Bridge Driver "Off-Diagnosis" which you are attempting, so I couldn't see what they demonstrate as the correct procedure, and (ii) their download licensing would prevent me showing it to you anyway, as the license prohibits public disclosure of code from a download. :-(

  • h) At the point in your code that you show in the screenshot (and you might not even be allowed to show that, based on the download license that I saw!) it seems you might be looking at the CTRL1 status bits after just step A in the procedure. That would be incorrect - you need to perform the other steps before then clearing the DS_STS bits and seeing if they remain clear.

    As it says after step A in the User Manual:

    The DS-Status Flags are still set in this state of the Bridge Driver, but since the Drain-Source-Current Sources are not enabled these flags do not have a meaning yet.

    So before you follow the other steps, including enabling the current sources later, then seeing the DS_STS bits "set" has no meaning at that point. It seems that you might be making that mistake in the interpretation of those bits (but I can't be sure, based on only that small amount of code visible in the screenshot).

I hope that gives you some ideas. As I said at the start, this is just a hypothesis, which I can't test without the hardware.

If possible, try to go back to a version of your code which you know was working, on a date before the first date you believe things "went wrong" (I hope you have some kind of SCM system e.g. Git, SVN etc.).

When the website became viewable again today, I noticed that you weren't getting any replies on the Infineon forums. I suggest you could also contact Infineon support directly through their "Technical Assistance Center (TAC)" if you need more help, or via whichever distributor you are using. Good luck!

  • \$\begingroup\$ First of all, I would like to thank you verymuch. I have no more forum left where i asked the problem but got any answer including Infineon forum. Thank you again for taking so much pain in going through the datasheet. Even if Infineon TAC is also saying we are working on my questions for last 1 month. \$\endgroup\$ – litun bls Dec 21 '17 at 15:26
  • \$\begingroup\$ I don't know How Infineon like automotive semiconductor MNC could make so much mistake in their datasheet. I have read in many other mistakes in their data sheet also. They never reply in their forum. Even If so called "TAC" is a third party agency who only receives the query and forward it to Infineon. They never speak or write mail directly. \$\endgroup\$ – litun bls Dec 21 '17 at 15:34
  • \$\begingroup\$ @litunbls - I'm sorry to hear about the difficulties getting official support on your problem. I have just one more suggestion: On this Infineon page they talk about customers getting free support, with 24-hr response for technical questions, from their "Preferred Design Houses" - and they give a list of those here. Consider asking the closest one to you? \$\endgroup\$ – SamGibson Dec 21 '17 at 16:01
  • \$\begingroup\$ Thanks SamGibson, As you are suggesting in (d) over current (LSx/HSx_OC_STS =1) appears if I switch on the Drive in the short condition(HSx/LSx_DS_STS=1). So root cause is HSx/LSx_DS_STS=1.I have taken care of all the things you have suggested but still HSx/LSx_DS_STS bits remain as set. \$\endgroup\$ – litun bls Dec 23 '17 at 1:17
  • \$\begingroup\$ Secondly there are 3 cases are pending with infineon regarding this External FET Drain-Source Short issue, Data sheet error etc. But they are telling, we are working on your cases for last 20 days. Earlier two guys Mr. Steve Raym and Mr. Gerrd Belz has written some mails regarding this problem but now there is no reply. What to do in this case? \$\endgroup\$ – litun bls Dec 23 '17 at 1:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.