Bricked my TPS544B20 using TI Fusion Digital Power Designer

I have some more information that I am going to describe in this email that pertains to my original issue.

It appears that the 12 to 5V regulator (TPS544B20) is disabled. The reason that this regulator is disabled is because of an over current fault on my board. The following registers show you how the device is programmed.

IOUT_OC_FAULT_LIMIT - Register 0x46. The default value is 0xF834 (set to 26A). The programmed value in my application is 0xF80C (set to 6A).

IOUT_OC_FAULT_RESPONSE - Register 0x47. The default value is 0x07 (set to Disable no retry). The programmed value in my application is the same.

IOUT_OC_WARN_LIMIT - Register 0x4A. The default value is 0xF828 (set to 20A). The programmed value in my application is 0xF80A (set to 5A).

ON_OFF_CONFIG - Register 0x02. The default value is 0x16 (Mode: CONTROL Pin Only; Control: Active High, Use TOFF_DELAY/TOFF_FALL). The programmed value in my application is the same.

VIN_ON - Register 0x35. The default value is 0xF011 (4.25V). The programmed value in my application is 0xF02C (11.00V).

VIN_OFF - Register 0x36. The default value is 0xF010 (4.00V). The programmed value in my application is 0xF02B (10.75V).

MFR_07 (PCT_VOUT_FAULT_PG_LIMIT) - Register 0xD7. The default value is 0x00 (UV Fault: –16.8%, PGOOD (falling): –12.5%, PGOOD (rising): 12.5%, OV Fault: 16.8 %). The programmed value in my application is 0x01 (UV Fault: –12.0%, PGOOD (falling): –7.0%, PGOOD (rising): 7.0%, OV Fault: 12.0 %).

All the other registers are the same as the default values in the datasheet.

Theory of what happened to my board:

1. I have two boards that were both programmed with the same values. Board #1 is a special build board that does not populate quite a few components including two power hungry processors and memory. Board #2 is a fully populated board.
2. I used the same script (TI manufacturing tool) to program both boards.
3. Board #1 (special build) has no issues. This board works fine. I did notice that I get an OC warning for the 12 to 5V regulator (trips at 5A) but I never get an OC fault.
4. Board #2 (fully loaded) has problems. So far I have seen the 12 to 5V regulator get “bricked” twice. I believe that the problem is related to the in-rush current. My theory is that the OC fault is being tripped and the regulator is disabled permanently. I am going to change the programming so that the this will remain at default (26A). This should fix my problem but I still want to bring the part on my board back to life!
5. I have tried to shunt the CONTROL pin to GND and then back to 3.3V but that does not reset the device. I tried this after reading the following in the datasheet. Why can’t I restart the device?
   1. There is no RESET to the device therefore the 1^st bullet in section 10.7 of the PMBUS spec does not apply.
   2. Not sure how to remove BIAS power in the 3^rd bullet. I did remove the input power (+12V) butt did not see the part come up.
   3. The 2^nd bullet refers to ON_OFF command via the PMBUS but I don’t have communication with the device because the part is shutdown. I don’t think this matters because we are setup for CONTROL pin only.
   4. I am wondering if reg 0x47 (IOUT_OC_FAULT_RESPONSE) should be set to Hiccup mode instead of Disable (no retry) mode. This way the regulator can keep trying to come up. Any thoughts on this?

 TPS544B20 Datasheet:

8.6.13.1 RS[2:0]
000: A zero value for the Retry Setting means that the unit does not attempt to restart. The output
remains disabled until the fault is cleared (See section 10.7 of the PMBus spec.)
111: A one value for the Retry Setting means that the unit goes through a normal startup (Soft start)
continuously, without limitation, until it is commanded off or bias power is removed or another fault
condition causes the unit to shutdown

PMBUS SPEC:

10.7.  Clearing A Shutdown Due To A Fault
Any device that has shut down due to a fault condition remains off until:
•  A RESET signal (if one exists) is asserted,
•  The output is commanded through the CONTROL pin, the OPERATION command,
or the combined action of the CONTROL pin and OPERATION command, to turn off
and then to turn back on, or
•  Bias power is removed from the PMBus device.

Any help would be much appreciated.

Regards,

Rudy

Hello -- 

Its not possible to damage the TPS544x20 through Fusion alone. The first "health" check I would do on the "bricked" devices would be to apply power, and measure the BP3 and BP6 voltages. These should measure ~3.2V and ~6.5V. If they do not, there is a more serious problem. If you scan for the device through Fusion, can you still find the 5V device?

A few things I would try for starters - increase IOUT_OC_FAULT_LIMIT to ~20A. Change IOUT_OC_FAULT_RESPONSE to "restart,"  change ON_OFF_CONFIG to "always converting." 

It might also be helpful to see a schematic. 

Hi Matt,

I haven't measured the voltages on BP3 and BP6 yet. I'll check these voltages this morning.

Every time I try and scan the "bricked" TPS544B20 on my board I get the same result. I can't see the device via the PMBUS.

I have already implemented your suggestions above with the exception of the "always converting" mode. In my application I need to have the CNTL pin enable the part.

Let's assume that BP3 and BP6 are good. What next? Is there a way to "unbrick" the device on my board? Per my previous post the datasheet talks about methods to clear a fault (section 8.6.13 IOUT_OC_FAULT_RESPONSE). I tried these methods and it did not work.

I can send you a schematic if you send me your email.

Thanks,

Rudy

Hi Rudy - my email address is mjschurmann [ at ] ti <dot> com. 

If the device is not responding to PMBus, then I wonder if it might be damaged. First, make sure that Fusion is scanning all of the addresses for DEVICE CODE.

Also, I would try Ohm-ing out the power FETs - i.e. lift the inductor, and ohm from VIN-SW and SW-GND. 

Hi Matt,

I just sent you the schematic via email.

Fusion is setup for Scanning Mode: DEVICE_CODE scan. It does not find any valid devices on my board. I can understand why it doesn't find three of the devices. In my design I have one TPS544B20 providing 5V to three other TPS544B20's. The main 5V TPS device is the one that is "bricked". I am assuming that since I don't have 5V to the other 3 downstream TPS devices that they will not respond to PMBUS commands. The main concern is that I can't communicate with the main TPS 5V device even though there is 12V present at the input (VDD).

"Also, I would try Ohm-ing out the power FETs - i.e. lift the inductor, and ohm from VIN-SW and SW-GND."

I already put back the inductor on the board. I would prefer not to remove the inductor again since I have already done this twice. I don't want to damage the part or the board. It isn't easy removing this part.

I do have a TPS544B20 from last week that was also bricked. We had it removed from the board. I can make the measurements OFF the board on the IC itself. Is this ok?

Thanks,

Rudy

Hi Matt,

I measured BP3 and BP6 for all 4 regulators on two boards. Board #1 (good board) Board #2 (bricked 5V). Here are the results:

Board #1 (good board):

5V0 regulator: BP6 = 6.458V, BP3 = 3.275V
1V2 regulator: BP6 = 4.989V, BP3 = 3.240V
T1_Core regulator: BP6 = 4.990V, BP3 = 3.266V
C29x_1V0 regulator: BP6 = 4.991V, BP3 = 3.269V

Board #2 (bricked 5V):

5V0 regulator: BP6 = 6.536V, BP3 = 3.256V
1V2 regulator: BP6 = 0.170V, BP3 = 0V
T1_Core regulator: BP6 = 0V, BP3 = 0V
C29x_1V0 regulator: BP6 = 0.90V, BP3 = 0V

Summary:

Looks like BP6 and BP3 on the bricked part (5V0) is ok.
BP6 and BP3 are essentially 0V on the 3 downstream TPS devices because there is no valid 5V0 input. This makes sense. I can get these to work by removing the output inductor from the 5V0 regulator and driving 5V0 from an external supply. When I do this I am able to communicate with the 3 downstream regulators using the PMBUS. I still can't communicate with the 5V0 regulator.

Question:

It looks like BP6 for Board #1 is not equal to 6.5V. Is this going to be an issue? I read the datasheet and it looks like it should work at ~4.9V. This voltage is used for the internal gate drive of the FET's.

Thanks,

Rudy

Hi Rudy -

Hmm... Those BP voltages look normal, within tolerance. Ohm-ing out a standalone device should be OK. We're just trying to determine if the device is physically damaged. The BP voltages function as controller controller supplies, so it should be "alive."

A few thoughts:

• Does it make any difference if you try to scan with the CNTL pin held low? I'm wondering if there might be some start-up issue that trips an OCP condition, causing the TPS544B20 to latch off awaiting a CNTL toggle. 
• Make Fusion is scanning all addresses, and that this 5V is responding to the correct address. One experiment to try would be powering up with one of the ADDRx resistors open/short to ground. This will force the PMBus address to 127d, which is out-of-range - so the other TPS544x20 devices will not respond to the same address
  • Unplug the adapter, and start Fusion. It will not be able to find any devices, of course, because the adapter is not plugged in. Click "change device scanning options" in the dialog that comes up. 
  • In the top right of this window, there is a drop-down menu, select DEVICE_CODE & DEVICE_ID & IC_DEVICE_ID (this selects to scan for any TI device on the bus). 
  • Click OK, plug in the adapter, and re-try.
• Do you see any activity on the SW, Vout nodes when you initially plug in 12V power? CNTL is pulled high on the schematic, so the device should try to start at least once, even if there is a fault being tripped. 

Hi Matt,

I measured the resistance between the following pins on a "bricked" TPS544B20 that was removed from the board.

VIN (pin 21) to SW (pin 12) = 2.615 Mega-ohm
SW (pin 12) to GND (pin 20) = 2.35 Mega-ohm

Rudy

Rudy,

Matt and I discussed your issue at some length earlier.

We have determined a couple of possible causes.

1) PMBus Data or Clock signal integrety or connectivity

  Check the DATA and CLK voltages on an oscilloscope during the Fusion Scan to make sure the TPS544B20 is receiving CLK and DATA signals from the PMBus Dongle.

  Check the soldering of the DATA and CLK pins on the TPS544B20 to make sure they are electically connected to the PCB.  Reflow with additional solder if necessary.

2) Solder Short between DATA or CLK and SMBAlert combined with a start-up OC fault

 This will show up in the prior test as a lack of signal on one of the pins, but will allow communication if the 12V source voltage is powered up while CNTRL is forced low to prevent start-up because SMBALERT will not be asserted (forced low) if no start-up fault is encountered.

3) One or more of the PMBus pins has been damaged

It is possible that during testing one or more of the PMBus pins has been exposed to an excessive stress (voltage or current) and become damaged.  If the CLK and DATA pins are solders and are recieving signal activity, you may need to remove the TPS544B20 from the board and replace it with a new device.

I would recommend selecting an OC Fault level of 10A or greater, even for nominal loads of 5A or less.  Loads during start-up, including charging the output capacitor, inductor ripple current and the +/- 3A OC tolerance can result in start-up OC faults when OC Fault is programmed below 10A.

Matt and Peter,

I was able to "un-brick" the TPS544B20. I sent a detailed email to Matt explaining what I did.

I will have some follow up questions for you tomorrow.

Thanks,

Rudy

Just to satisfy my own curiosity, what do you mean by the term "bricked"?

A brief synopsis of the issue for future reference:

The i2c pull-ups were generated from a 3.3V supply downstream of the 5V. The 5V had a low OCP setting, and IOUT_OC_FAULT_RESPONSE="Shutdown, Do not Restart". At initial power up, the 5V would trip OCP, then shutdown, so i2c communication was not possible because no activity was showing up on CLK and DATA. 

Two step solution: (1) Enable the internal pull-ups in the TI Fusion SAA adapter to enable communication with the device, even if it is not regulating, (2) raise the OCP threshold so it does not trip at start-up.

Question I have/misunderstanding: When the 5V was 'bricked,' you should also NOT have had communication with the other three devices, is that right?

John,

I used the term "bricked" to mean that the device was shutdown and unable to communicate on the PMBUS.

Rudy

Matt,

You are correct in your summary of the problem and resolution.

You are also correct in that I was not able to communicate with the 3 downstream TPS devices. I did try an experiment where I removed the output inductor from the 5V main regulator and then connected an external bench supply to the output inductor pad. I was able to generate 5V to the three downstream devices. In this case I was able to communicate with the 3 downstream regulators but not with the main 5V regulator. I am still not 100% sure why I wasn't able to communicate with the 5V regulator in this experiment.

Thanks,

Rudy

Hi Matt,

I never got an answer for the following question:

It looks like BP6 for Board #1 is not equal to 6.5V. Is this going to be an issue? I read the datasheet and it looks like it should work at ~4.9V. This voltage is used for the internal gate drive of the FET's.

In my design I have 3 TPS544B20's where the VIN,VDD= +5.0V. The BP6 for each of these is around 4.90V. Is this an issue or does it need to be 6.5V nominal?

The datasheet has the following text:

The TPS544B20 and TPS544C20 devices include an internal linear regulator to supply bias for internal logic and the power MOSFET drivers. The BP6 regulator steps down the VDD voltage to approximately 6.5 V when V VDD is above 6.5 V, or operates with a maximum of 100-mV dropout when V VDD is less than 6.5 V. In this case, the BPEXT pin should be connected to PGND.

I just want to make sure that I am not going to run into problems when BP6 is not at 6.5V.

Thanks,

Rudy

Apologies, I though I had answered this via email. 

BP6 is an LDO powered from VDD. With VIN=5V. When VIN is less than 6.5V, the output of the BP6 regulator will be equal to VIN minus the dropout you mentioned above. This is perfectly normal.