PTD08D210W: FLT flag being set from power on

As an additional bit of information, here's a zoomed in view of the FLT signal rising with the 12V input:

Plots are:

1. (Green) FLT flag
2. (Pink) 12V input rail
3. (Blue) 1.5V rail, not really useful was just on the screen.

Hi Bryn,

Please note that the supply voltage for UCD9248 needs to have a slew rate of at least 0.25 V/ms in order for the device to start up properly.

The fact that when you connect your hardware to a PC through the USB programmer, everything is fine and when the programmer is detached it trips the FLT, makes me believe that this might be caused by a grounding/noise issue.

Could you please look at the PWM-A, PWM-B, SRE-A and SRE-B signals when this happens and check if any shoot-though event during power up?

Alternatively Disconnect the SRE-A and SRE-B from UCD and connect the PTD pins to ground. Then try to see if you can still duplicate this problem.

My hypothesis is that the FLT flag goes high due to a real high current in the high side FET getting detected.

Regards, 

See attached screen shot of the fault condition:

1. (Green) Vin
2. (Pink) FLT-B
3. (Blue) PWM-B
4. (Purple) SRE-B

Does this answer your question?

Any ideas why the setting to ignore FLT faults on start up is not being heeded?

Thanks,

Bryn

Hi Bryn,

Couple of more comments.

The UCD9248 should have an option of turning the power stage on later by a command and not immediately with the board being powered up.
Can you try to set UCD9248 to not switch the PWMs at power up and see if that helps.

Also the effect of USB programmer being connected or not may be due to the supply of 5V coming from the USB port.
Is the USB power connected to your target hardware?

Regards,

Hi,

By option do you mean the Ton delay, or is there another option?  At the minute Rail 1 on the first UCD is set to wait 500 ms before starting regulating (using Ton delay), then the other 6 rails in the system, spread across the two UCD's are set to sequence in turn following that, so there is a significant delay from board power on until the first rail starts.

See attached for the section of schematic that has the USB programming cable attached:

As you can see, no 5V connection we just connect the ground and the 4 PMBus signals.

Thanks,

Bryn 

Did the plots shed any light on the issue?

Bryn

Since UCD9248 is PMBus compatible it should support the ON_OFF_CONFIG command.
I am referring to the option that waits for the control pin to go high, and only then starts the switching in order to turn the rails on.

Since you said that this only happens at the first time the hardware powers up, I am wondering if we can fix this by letting the hardware power up first and all voltages settle, and only then turn the rails on by toggling the control pin.

If this does not help, then please disconnect the SRE-A and SRE-B from UCD and connect these PTD pins to ground. Then try to see if you can still duplicate this problem.

We have to understand whether the PTD module wrongfully raises the FLT flag, or the PTD module does this because the PWM waveforms from UCD are sometimes not proper. By grounding the SRE-A and SRE-B, we can make sure that the upper FET and the lower FET do not ever turn ON together. As any overlap of PWM and SRE signals will cause the FLT flag to be raised.

The logic/circuit in the PTD module is relatively simpler than in UCD, that is why I am guessing that the PWM signals from UCD may be the cause.

Regards,

For normal system operation there won't be a programming cable attached so I can't relay on being able to manually control it to 'on'.  The voltage rails settling is why I have a Ton delay of 500 ms from power on before all the rails start.  And as you can see from my plots above the FLT flag is set immediately from power on, well before the UCD attempts to control any of the rails to on.

The capture I made above clearly shows SRE not moving from ground, PWM having a slight blip upwards and the FLT flag being set, so I don't see what grounding the SRE's will prove, that combined with the fact I would have to butcher the board to achieve it makes me reluctant to try.

Understood. I do not know UCD9248 that well, I will refer your question regarding the setting to ignore FLT to my colleague in the UCD group.

Seems like the blip in PWM-B is about 1 volts, that is more than I expected.

I wonder if that causes the FLT to raise, will get back to you as soon as I get my colleague's feedback.

Regards,

Hi Bryn,

According to the UCD7242 (the FET driver used in the PTD module) datasheet, the blip of about 1V should not turn on any PWMs.

But on the other hand we see that FLT rises exactly when the blip happens.

To debug this we could probably replace the UCD with another UCD that does not present a big blip and see if the issue goes away.

But if you managed to ignore the FLT so the rails do not shut off as discussed in the other thread:

https://e2e.ti.com/support/power-management/f/power-management-forum/997996/ucd9248-t-on-delay-overrides-t-rise-flt-not-being-ignored-on-start-up

May be we can stop our investigation and proceed with the above workaround?

Regards,

Hi,

Why should the PWM turning on cause a FLT, surely that's normal behaviour, as long as its not on at the same time as SRE, why should it be flagging a fault?

We have tried replacing the UCD's on a different PCB and afterwards we were still seeing the same issue, so unless there are multiple strange units in a batch I don't think its a part issue.  I will attempt to catch a normal start up (without FLT) on a scope and see if the 'blip' is still there.

I am concerned I have only partially ignored the FLT faults as mentioned in the other thread, as the ignore setting isn't working I've had to declare them as GPI's and I'm limited as to how many I can do that to, so some rails are still connected.  So ideally I'd like a proper solution to this as if the FLT fault moves to a different rail it may come back to bite me.

Right I've captured a few more plots which I think demonstrate its the presence of a PWM pulse that cause it, but not always, so the plots are as follows, in all plots trace 1 = Vin, trace 2 = PWM, trace 3 = FLT:

1)  Power on with TI programmer attached.

2)  Power on with Ti programmer detached, and FLT being set.

3)  Power on with Ti programmer detached, and FLT not being set.

4)  Power on with Ti programmer detached, and FLT not being set.

So, it seems if the programmer is attached you never see a PWM pulse, I did loads of captures and they all looked identical.

With the programmer detached you always see a PWM blip, and sometimes occasionally this flags a fault.

So the questions, why does the programmer cable attached cause the PWM to stay low?

Why does a PWM blip sometimes cause a FLT, as I can see no difference in levels or shape between one that does FLT and one that doesn't?

Bryn

Hi Bryn,

Thank you for providing the new screen shots.

It will be interesting to look at the VCC of UCD9248 during the power up, with or without the programmer attached and see if there is any difference. If there is no difference in VCC waveform then, the presence of the programmer only affects the grounding and noise profile and we will focus on that.

I have also contacted the group in TI that supports UCD7242 (The MOSFET driver inside the PTD module) to see if they have seen anything like this.

It seems like the new plots show that the rise in FLT has something to do with the blip in the PWM signal.

From the little information that I have about UCD9248, the blip should be smaller with faster slew rate in power up of the VCC. But you have mentioned in the beginning that this actually happens only with power supplies that are faster in your labs, and that is strange.

I wonder if this has anything to do with the way AGND and PGND pins of the module are connected.
The AGND pin of the module should be connected to a quite part of UCD9248 grounding and away from Power ground noise.

Regards,

Hi, please see attached.

This is the section of schematic we use to generate the 3v3 for the UCD's from our incoming 12v Rail.

Each UCD has its own transistor circuit.

The following plots were taken on start up with and without programmer attached, for all plots the traces were:

1) (Green) 12V main Vin.

2) (Pink) 3V3 for the UCD generated by the above circuit.

3) (Blue) PWM for the rail.

4) (Purple) FLT for the rail.

.

1)   Programmer detached, no FLT flagged.

2)  Programmer detached, FLT flagged.

3) Programmer attached, no FLT flagged,

Having the programmer attached made no difference to the start ups of the 3v3, however I discovered you need the cable plugged into the USB of the laptop to block the FLT flags and looking at the plots I can see why, it looks like the UCD's power rail is being held at about 1.5V even with the main power off, which I am guessing can only be via the pull up resistors on the PMBUS which are being powered via the USB programming cable.  Is this enough to make is start and hence when we turn the power on we don't get the weird start up pulse on PWM?

Bryn

Hi Bryn,

Yes.

The 1.5V pre-bias is what I was guessing that is happening, and indeed it builds up through the pull-ups or other leakage.

This prevents UCD from generating the blip on the PWM output.

Regards,

Ok, so that explains why the programmer being attached makes the problem go away, still doesn't help us in regards why its flagging a FLT in the first place, any ideas?

Bryn

Hi Bryn,

Yitzhak will feedback to you shortly.

Thanks,

Lishuang

Hi Bryn,

Even if we had a good idea regarding why this blip triggers the FLT flag, practically this would not solve the issue.

The issue can be prevented either by having the "ignore FLT during startup" in UCD work , or choose UCDs that have less significant blips and replace the current UCDs with those. As you can see, even with your current UCDs one PWM channel always works, and that must be due to the fact that the blip on the working channel is less significant.

Since you already have another thread regarding this issue:

https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/997996/ucd9248-t-on-delay-overrides-t-rise-flt-not-being-ignored-on-start-up/

I am closing this thread. Let's follow up our discussion in this regards via the other post.

Regards,

Hi,

Are you saying that this startup 'blip' is known behaviour from the UCD's and there is no settings we can use to make it hold those lines low on startup and remove the blip?  Hence the only thing we can do is try a few parts and attempt to pick the ones with the smallest 'blips'?

Did you get anywhere with working out why the PTD08D210W seemingly is flagging a fault when the PWM signal is driven coincidentally with the Vin?  Is that more known erratic behaviour and hence nothing that can be resolved?

In which case then, yes I agree with you, if this all down to marginal erratic behaviour from two of your parts interacting, i.e. occasional blips & occasional FLT flags on blips, that would match what I am seeing in that some boards work fine, some very occasionally FLT, some regularly FLT, but its all very intermittent, then my only solution is to attempt to mask out the incorrect FLT flags.

Fingers crossed lets hope I get somewhere on that thread then.

Regards,

Bryn

Hi Bryn,

Let's just merge the threads into a single thread as these are related.

Regards,

Hi,

I have no problem with merging the threads if the only solution I am going to get is via the software.  But you didn't really answer my question, are you saying this behaviour is expected or known so there is nothing we can do about it, other than make the software handle the random faults.  It just seems to me the right thing to do is stop the erroneous faults not mask them, unless that is impossible to do.

Regards,

Bryn