TPS65217: Spike of BATT pin

Hi Jay,

Datasheet says that 22ms power path deglitch is for voltage increasing? Does this mean that the deglitch only applies to voltage detection and not voltage REMOVAL detection?

I may be understanding this wrong.

Regards,

Jesse

And could it be in someway related to this statement  from the datasheet:

9.3.9.1 Shorted or Absent Battery

Jesse,

Can you confirm the time scale in the initial scope shot shared in the thread? Is it 5ms/div as it appears in the lower-right hand corner?

Can you provide a scope shot showing VBAT, SYS, and AC all on the same plot?

Thanks,

Brian

Jesse,

I would also be interested to know the value of Register 0x04 (CHGCONFIG1), bit D0 (CHG_EN) used in your system.

The default/reset value of this bit is '1', but you mentioned that there is no Battery in your system. In the absence of a battery, there may be measures we can take be writing values in the Register Map that will prevent your glitch on VBAT.

There is a whole section in the TPS65217 datasheet's Application section titled "10.2.2.2 Battery-Less/5-V Operation" (pages 75-76). Does your system match Case 1/2 or 3 more closely? How is your TS pin terminated? 

Please refer to this section and verify your schematic is connected as shown in Figure 56 and read through the functional differences in the first column of Table 36, titled "POWER SUPPLIED THROUGH AC PIN"

Hi Brian,

Yes, the timescale is indeed 5ms/div in the first image.

Here's a scope shot of the AC, SYS, and BAT pin.  For this image I had to disable the AC power path to perform a shutdown. The only board I have available for scoping has a damaged RTC section so shutdown by ALARM2 is unavailable. BAT pin behavior and other symptoms are similar though. 

(Pink-AC; LightBlue-SYS; DarkBlue-BAT)

CHG_EN bit is left at its default enabled value (1). We've scoped and tried disabling this register before and still saw the same spike, although we did not study the differences in detail. The spike may be occurring a couple microseconds later or something like that.  I think the spike will be there regardless of the charger settings. The spike we're seeing is when SYS is connected to BAT during shutdown and therefore following it all the way to its steady state.

We have our circuit configured similar to case 1/2 of section 10.2.2.2. Only difference I see is we don't have BAT and BAT_SENSE shorted to each other - all three are floating. TS is also left floating just as the left configuration in figure 56.

Regards,

Jesse

Can you please describe the "unexpected reboot" in more detail? Do you mean the SYS rail comes back up on its own, unexpectedly?

I apologize for not asking before, but can you please also probe the PWR_EN pin and show it on the same scope plot as AC, SYS, and VBAT?

I understand that you forced the VBAT spike on your last scope shot by disabling AC power path because one of your boards was damaged, but I would prefer to only see scope shots that are taken when an "unexpected reboot" occurs.

I'm trying to set up a test in the lab to recreate your issue, and I will need as much relevant info as possible relating to the TPS65217 pins. An "unexpected reboot" in your system needs to be quantified in terms of the TPS65217 pins, if possible, so provide as many details as you can.

Hi Brian,

Every time we call a shutdown the PMIC would completely shut down then automatically restart after 1 second. We have BAT pins floating and USB connected to ground.

The unexpected reboot happens no matter what shutdown method we use, this includes disabling the AC power path. So, the scope shots I've posted are all rebooting.

Whenever the reboot occurs, we get an interrupt signal with the register reading 0x02 saying there has been an AC status change. Our AC in is at a constant 5V all throughout. Some noise in there but nothing larger than 400mV still a large margin from AC detect thresholds. Unless the spike on BAT was sufficient in changing the criteria to a Battery present situation.

The VBAT spike also occurs no matter what shutdown method we use. 

I'm sorry I can't scope PWR_EN and VBAT at the same time since I'm only probing at exposed vias for these signals.

I have some older scope shots from another project board that's experiencing the same issue but at less occurrence.

(Lightblue-SYS; pink-LDO4; green-LDO1; darkblue-PWR_EN)

This was one of our suspects before, but it would occur regardless if there was a reboot or not. What's happening is, LDO1 is losing its regulation early due to the dropping SYS voltage. So once it loses regulation, LDO_PGOOD is asserted putting the SoC's RTC section into reset state where PMIC_POWER_EN is default HIGH. Then since the voltages are already dropping, the signal on PWR_EN starts to go down with it's pull voltage.

We were able to control this by controlling the drop on SYS with a large capacitor.

It still goes up, much later and for a much shorter period. However, unexpected reboot occurrence rose to 100%. We think the delayed SYS drop is also affecting the spike on BAT therefore affecting AC detection if possible? We've concluded that the pulse on PWR_EN isn't the cause of the unexpected reboot, but do you think such a pulse at that point of shutdown could still bring the system back up?

Here's a scope shot of VBAT with the exact same conditions as the previous graph.

(darkblue - BAT)

If you're recreating the issue, could you post a scope shot of the behavior of VBAT in your environment? I want to compare it with ours in detail.

Thank you very much, I appreciate all the help.

Best regards,

Jesse

I'm also curious about the behavior of PWR_EN and SYS, as well, in your environment.

Jesse,

Yes, I have some ideas. I apologize for not mentioning in advance that I was observing the US Holiday last week.

I took some measurements and was getting bizarre results until I realized that on the TPS65217EVM the PWR_EN pin is pulled up by the USB2ANY USB to I2C controller by default. The IPG_UI is helpful to Read & Write registers, but I didn't notice it was also applying 3.3V to PWR_EN at all times via a GPIO setting.

I have removed the resistor in this path now and will test again.

Hi Brian,

No worries. I hope the holiday season went well.

PB_IN is left floating as per schematic checklist recommendation since it's internally pulled up.  We've scoped this signal before and it looks like this:

The 5V on the PB_IN line drops to around 3.8V when SYS drops. But, if I'm not mistaken, datasheet says PB_IN logic high is from 1.2V to Vin. We tried to pull this up externally to our AC voltage, but still got the same reboot.  Exact same situation on the nRESET pin.

Regards,

Jesse

Jesse,

You said "The unexpected reboot happens no matter what shutdown method we use".

What methods of shutdown have you tried?

Obviously you've attempted disabling the AC Power Path via AC_EN (writing a '0' to bit 5 of Reg. 0x01).

Have you also tried using the SEQDWN & INSTDWN commands (writing a '1' to bits 0 & 1 of Reg. 0x1E, respectively)? I actually don't know what I2C message "ALARM2" sends to the PMIC.

Any other methods you have tried in digital or analog that I'm not thinking of?

Can you please verify that VBAT and TS are left completely floating in your schematic?

• Is there a 10uF cap on VBAT? If so, remove it
• Is there a large pull-down resistor (75-100k) on TS? If so, remove it

Since you have said the "unexpected reboot" happens after 1 second, I believe you are transitioning to the "Wait 1s" state on the left-hand side of the Global State Diagram on page 38 of the datasheet.

After the 1 second delay, your system transitions to the OFF state and receives a 'Wakeup' condition.

The 'Wakeup' triggers are listed in the NOTES section below the diagram. One of these triggers must be causing your re-boot, which is why I suspected it was PB_IN at first.

Based on our conversation, we can eliminate: USB rising, PB_IN falling, and a RESET state (caused by 8s long PB press).

SEQUP = 1 is impossible if the MCU has no power.

The only remaining Wakeup event would be AC rising, which I understand would be the reason for you original question.

If there is a 10uF cap on VBAT (even though the pin is effectively floating), remove it and re-test. And please ensure that ALARM2 translates to "SEQDWN" command for your standard shutdown method.

And finally, if none of these options work, what is your Max voltage on AC? If over-voltage protection is not required in your system (VAC=5V Max), then you may want to consider wiring up your design as shown on the right-hand side of Figure 56 on page 76 of the datasheet:

This is effective because VBAT is the primary supply to SYS of the TPS65217 power path, and powering from AC without any connection at VBAT can lead to tricky situations like this.

Hi Brian,

Thank you very much for the detailed run through.

Brian Berner said:

What methods of shutdown have you tried?

We've tried the following methods, all of which end up in a reboot:

-OFF bit set to 1, then PWR_EN pulled LOW by SoC's ALARM2 (this is our main and preferred method)

-SEQDWN bit set with out INSTDWN

-SEQDWN bit set with INSTDWN

-OFF bit and PWR_EN LOW with INSTDWN

-AC power path disable

Brian Berner said:

Can you please verify that VBAT and TS are left completely floating in your schematic?

Yes, BAT, BAT SENSE, and TS pins are all left floating.  We actually have a different project board which has a 10uF capacitor on BAT and BAT sense, and a 75kOhm resistor on TS. This project board never experienced the unexpected reboot. It's interesting actually, we scoped the BAT pin of this board and got this:  (Pink-VAC, Blue-VSYS, Green-VBAT)

So we thought, since VBAT passed VUVLO but VAC-VBAT never became less than 125mV, it was avoiding the AC detect therefore not rebooting.  But, when we removed the 10uF capacitor and recreated the VBAT behavior of our rebooting boards, we still didn't get this board to reboot at all on a shutdown.

Brian Berner said:

And finally, if none of these options work, what is your Max voltage on AC? If over-voltage protection is not required in your system (VAC=5V Max), then you may want to consider wiring up your design as shown on the right-hand side of Figure 56 on page 76 of the datasheet:

This would be ideal, but we cannot carry out such a big change this point in time. It would require going back to very early stages.

We were actually able to prevent the reboot from occurring by setting the AC current limit to 500mA (PPATH control register's bits 3 and 2) before going through with our shutdown routine (OFF bit set to 1 then PWR_EN pulled LOW). But, we still need to find the cause of the reboot and why this patch solution is preventing the reboot for reliability and quality reasons.

Thank you again for the detailed responses. We really appreciate it.

Best regards,

Jesse

Hi Brian,

Just updating this.

I just realized recently that battery detection is dependent on the BAT_SENSE pin. And since we have this pin floating, the spike on BAT pin shouldn't be affecting AC detection at all. Am I correct?

I'll work on getting a scope shot of this pin.

But, in the meantime, do you have any ideas of where else we should be looking at?

Thank you very much!

Best regards,

Jesse

Jesse,

Just wanted to make sure you didn't think I was ignoring your replies.

I don't think the issue has anything to do with AC Detection, and I never have even though this is the initial question from TQ. I think the issue is related to the perceived presence of a Battery during the VBAT spike.

I still have not been able to re-produce a spontaneous re-boot without creating a falling edge on the PB_IN pin.

Can you set up your scope to trigger on the falling edge of PB_IN and show VBAT on the same waveform? With a shorter time scale (10-500us/div) you may be able to see PB_IN go lower while VBAT is rising during the "spike". 

If you do notice anything, could you try the test again with PB_IN pulled up to the AC pin instead of floating?

Hi Brian,

Don't worry about it. I was actually on holiday for a couple weeks.

Do you think that the AC status change interrupt is not the cause of reboot but just a byproduct of the actual cause?

PB_IN as well as nRESET both go down to about 3.8V during shutdown (regardless of reboot or not), and because of this we tried pulling them up to AC, but still get the reboot.

 (Here's an old scope shot of PBIN. I can't scope anything at the moment because we have it set in a different condition for tests.)

Now, to prove that BAT voltage wasn't the cause of reboot we added a 10uF capacitor to ground on BAT and BAT_SENSE pins. This would limit and delay the voltage on BAT pin. Surprisingly, this prevented the reboot from occurring, we've tested 100 times.  Here's the waveform:

 (yellow - SYS_5V, green - VBAT)

Our theory is that since VBAT is going above 3.5V, the thresholds for AC/USB detection change and would require a very small transient on AC to achieve a VAC-VBAT < 125mV condition. We have AC hooked up to a switching regulator, so we're guessing that the sudden drop in PMIC load on shutdown maybe causing a transient on that regulator when it switches to power saving mode. I'm trying to find that transient now.

So, you are correct. The issue is due to the perceived presence of a battery during shutdown. But that perceived presence is allowing a wakeup condition from somewhere, whether PB_IN or AC. Interrupt registers are suggesting AC detection, but we won't dismiss PB_IN being a factor just yet.

Thank you very much for the assistance, Brian.  We appreciate it.

Best regards,

Jesse

We've looked into PWR_EN before, actual results are in the page before this on the same thread. We haven't ruled it out, but we have the same behavior on PWR_EN regardless of a reboot or not, and with a OFFbit = 1 PWR_EN pulled LOW shutdown.

We're also avoiding the SEQDWN shutdown at the moment because of leakage that keeps the 3.3V LDO4 at 2 something volts instead of 0V, causing a damaging condition for the SoC. It was pointed out in this forum that this is a known issue in Beaglebone based designs.

So, to make things clear, at the moment we have been able to prevent the unexpected reboot with 2 separate fixes.

1. Setting the PMIC AC current limit to 500mA before calling an OFFbit=1, PWR_EN pulled LOW shutdown. And,
2. shorting BAT and BAT_SENSE (pins 4,5,6 of PMIC) and connecting a 10uF capacitor to ground, and shutting the system down with OFFbit=1 and PWR_EN pulled LOW.

Also, just to confirm:

Brian Berner said:

If there is any noise on PWR_EN, a boot/re-boot cycle may be entered because it is edge-triggered

Isn't PWR_EN level sensitive as stated in datasheet section 9.3.1.1 Power-Up Sequencing: The PWR_EN pin is level sensitive (opposed to edge sensitive)?

My apologies, PWR_EN and all inputs are level-sensitive. The common occurrence of "rising edge" and "falling edge" in the datasheet tripped me up. I was looking for "Low-to-high" High-to-low" transition.

I have spent some more time studying the part's response to various digital inputs (I2C writes and GPIOs) and have come to the following conclusions based on your original list of shutdown methods:

• OFF bit set to 1, then PWR_EN pulled LOW by SoC's ALARM2 (this is our main and preferred method)
  • Pull PWR_EN Low ONLY
  • When an "ALARM2" happens, DO NOTset the OFF bit to '1'
    • PWR_EN supersedes OFF bit to '1'
    • if OFF bit is set to '1' without pulling PWR_EN low,  then nothing happens
• SEQDWN bit set with out INSTDWN
  • Good, stable method
• SEQDWN bit set with INSTDWN
  • What is the purpose of this method?
• OFF bit and PWR_EN LOW with INSTDWN 
  • Do not use OFF bit
• AC power path disable

• Do not disable AC power path if it is the only supply to the system

I hope I can provide you some more logical reasons for these answers based on the state machine and comments in the datasheet, but this is an objective test method to help you avoid any future problems.

Hi Brian,

Thank you very much for the answers.

Brian Berner said:

PWR_EN and all inputs are level-sensitive

But, doesn't the datasheet say that AC detection, USB detection, and PB_IN are all edge sensitive as opposed to PWR_EN being level sensitive? I may have understood incorrectly.

Brian Berner said:

DO NOTset the OFF bit to '1'

Not setting the OFF bit to 1, whether with a PWR_EN or SEQDWN shutdown, will put the PMIC into a RTC only (sleep) mode which leaves LDO1 ON. We've tested this and it's not an acceptable condition.

Brian Berner said:

SEQDWN bit set with INSTDWN

• What is the purpose of this method?

We were testing the effect of having all the voltage rails shutdown simultaneously.

Brian Berner said:

Do not disable AC power path if it is the only supply to the system

Understood and we will avoid this method completely.

So we're left with only one option for shutdown, which is OFF bit=1 and PWR_EN pulled LOW. This works fine on the Beaglebone black and countless other Beaglebone based designs, and has been the preferred method of shutdown in multiple forum threads. But, for some reason we're getting a reboot in our case.

Jesse,

I fear you and I were both suffering from a misreading of the data sheet. I don't think "Rising Edge" and "Falling Edge" can be read literally and here is why:

Since all I/Os covered are by "LOGIC LEVELS AND TIMING CHARACTERISTICS (SCL, SDA, PB_IN, PGOOD, LDO_PGOOD, PWR_EN, nINT, nWAKEUP, nRESET)" on Page 12, this tells me that all of these pins have the same I/O structure. For pins that are strictly In or Out, they will have only contain half of the circuit.

And because an AC Interrupt (AC power status change interrupt) is generated with the digital resets, as in flipping the AC Enable bit, this tells me the AC input is level sensitive. USB has the same comparator circuit as AC, so USB must also be level sensitive.

"So we're left with only one option for shutdown, which is OFF bit=1 and PWR_EN pulled LOW. This works fine on the Beaglebone black and countless other Beaglebone based designs, and has been the preferred method of shutdown in multiple forum threads. But, for some reason we're getting a reboot in our case."

I spoke to someone familiar with the BeagleBone Linux driver for the TPS65217 and he told me that:

The driver sets the OFF bit of the TPS65217 to '1' during Boot (or the 1st time the driver probes the PMIC). The actual PMIC_PWR_EN output of the AM335 is pulled low at a much later time when the processor determines it needs to physically turn off the PMIC

This long delta between when the OFF bit is set to '1' and PWR_EN goes low seems to be quite different from your description. Your description sounds like OFF bit = 1 and PWR_EN = Low occur in back-to-back functions in code. Is this correct?

Are you using the AM335 with a Linux kernel? If not, are you using a RTOS (real-time OS)?

If you are using Linux, why wouldn't you be using the Linux PMIC driver for the TPS65217?

Jesse,

"Not setting the OFF bit to 1, whether with a PWR_EN or SEQDWN shutdown, will put the PMIC into a RTC only (sleep) mode which leaves LDO1 ON. We've tested this and it's not an acceptable condition."

You don't want LDO1 on? If AC is stable & LDO1 is off, then SYS must also be off (see STROBE 15 in Figure 4 of the datasheet).


What is controlling PWR_EN? It appears to me that if SYS and LDO1 are OFF then nothing downstream (AM335x) will have any power left to toggle the PWR_EN bit back to high.

Why can't you control the power upstream and just cut the voltage to the AC rail instead?

Hi Brian,

Thanks again for all the input.

"Since all I/Os covered are by "LOGIC LEVELS AND TIMING CHARACTERISTICS (SCL, SDA, PB_IN, PGOOD, LDO_PGOOD, PWR_EN, nINT, nWAKEUP, nRESET)" on Page 12, this tells me that all of these pins have the same I/O structure. For pins that are strictly In or Out, they will have only contain half of the circuit.

 And because an AC Interrupt (AC power status change interrupt) is generated with the digital resets, as in flipping the AC Enable bit, this tells me the AC input is level sensitive. USB has the same comparator circuit as AC, so USB must also be level sensitive."

This makes sense, but can it be possible that AC Interrupt is generated by a "digital" signal outputted by an edge detecting comparator on the AC line?

"Your description sounds like OFF bit = 1 and PWR_EN = Low occur in back-to-back functions in code. Is this correct? Are you using the AM335 with a Linux kernel? If not, are you using a RTOS (real-time OS)? If you are using Linux, why wouldn't you be using the Linux PMIC driver for the TPS65217?"

That's correct, OFF bit is set to 1 only during the shutdown routine. We're using Linux V3.14. I'll have to check with the software team if we did or didn't use the Linux PMIC driver. Either way, the same power management software was used in some of our other projects with similar configurations, but don't experience this issue. 

"You don't want LDO1 on? If AC is stable & LDO1 is off, then SYS must also be off (see STROBE 15 in Figure 4 of the datasheet). What is controlling PWR_EN? It appears to me that if SYS and LDO1 are OFF then nothing downstream (AM335x) will have any power left to toggle the PWR_EN bit back to high. Why can't you control the power upstream and just cut the voltage to the AC rail instead?"

No, we do not want LDO1 on. We want the system to go into OFF state rather than SLEEP and actually prefer SYS to go OFF. We have a couple other similar designs and not all of them have this issue of rebooting on a shutdown. We want to keep them all as uniform as possible especially in the power management section. In other boards we have a switch hooked up to PB_IN to wakeup the PMIC, instead of using PWR_EN (which isn't listed as one of the methods to wakeup the PMIC from OFF state in the datasheet). We're not controlling the power upstream to cut the voltage because the PMIC should be capable of this itself.

"It seems were are getting closer and closer to a discussion on the TPS65217 PMIC Drivers and further away from a power glitch causing an issue with the device. As you say, the Beagle Bone Black works wonderfully. A lot of this is due to the Drivers being mapped perfectly to the TPS65217 Register Map for system-wide state machine transitions."

Again, I'll have to confirm with our software team about the PMIC driver used, but the method used to bring the PMIC from ACTIVE to OFF state was followed closely.  There aren't really that much registers in the TPS65217. In the meantime, I'll look into that document.

Right now, considering that the same shutdown routine software didn't reboot on some of our other designs, we're trying to confirm why the 2 methods (AC current limit set to 500mA and a 10uF cap to ground on BAT and BAT_SENSE) mentioned in an earlier reply is preventing the reboot on a shutdown and if it's the solution to the root cause directly or just patch solutions that supersede the actual cause?

Regards,

Jesse

Jesse,

I am not discouraging use of the battery-less operation. I am simply trying to re-state what is mentioned in the datasheet in a more straight-forward way.

Some people would call it "reading between the lines" or "discouraging", but I do not believe I am contradicting the datasheet. One of the many purposes of the forum is to assist designers in interpreting datasheets and dissecting the intention of the info.

The "Typical Application" section, shown in Figure 55 on page 74 of the datasheet is the intended use case and it does show a battery.

All other intended use cases would be included in similar sections titled "Typical Application #2" and #3 and so on.

The next section titled "10.2.2.2 5-V Operation Without a Battery" are alternative use cases in Figure 56. They are not ideal but TI is providing suggestions on how to use the device in this way.  A while back I proposed you implement the design in Figure 56 but unfortunately you replied saying it was too late to make this type of change. Therefore, we tried to move forward and solve the problem in another way.

Personally, I would have used Section # 10.2.3 or Section 10.3 as the numbering and use some stronger wording if I had written the datasheet.

Either way, this section was added to the datasheet after the Beagle Bone Black was released using the TPS65217 without a battery. The Beagle Bone Black mentions the use of a battery, but there are restrictions on selling/providing development kits with batteries and it is much easier to ship these kits without batteries. The AM335x Linux Kernel also provides drivers for other PMICs that do not have a battery charger (such as the TPS650250 and the TPS65218).

In summary, I am not discouraging the use of the TPS65217 without a battery, but since a new user responded to the thread I am quickly trying to avoid the propagation of issues through their design process.

Hi Brian,

I understand what you're saying and it does makes sense to avoid the propagation of the issue by suggesting a full proof but drastic change.

But, since the behavior is occurring in a datasheet mentioned, alternative (although non-ideal) typical application it's hard for the user to perform or get authorization for big hardware changes when the root cause of the behavior still isn't known.

Thank you, Brian, for the usual support. We really do appreciate all the info and insights we get from this community.

Best regards,

Jesse

Brian Berner said:

AC detection is merely an interrupt that means the TPS65217 device was shutdown and now it is not.

Whenever the part is shut-down, the Register Map will reset to its default values. Whatever power supply is available at start-up will generate the interrupt.

I'm not sure if this is completely correct. In the case of a Beaglebone black based design which doesn't experience this reboot on shutdown behavior, has no battery and only supplied by AC input, but has a push button installed on PB_IN:

• When: PMIC is shutdown completely -> AC input kept at 5V -> then PB_IN asserted to turn the PMIC ON 
  • Interrupt register will only show that the PB_IN interrupt was generated (0x04). (Make sure you read the interrupt register before performing this test to clear the interrupt register from previous events)
• But, when: PMIC was shutdown completely -> PB_IN asserted to turn on the PMIC (interrupt register was NOT read so that the register wouldn't be cleared) -> PMIC completely shutdown again -> AC input removed -> AC input plugged in to turn the PMIC ON

• • Interrupt register will only show that an AC interrupt was generated (0x02).

It seems that interrupt register values are kept as long as the PMIC is supplied with enough voltage even if it is in OFF state.

Brian Berner said:

1) Use the SLEEP state if possible and avoid entering the OFF state, which will essentially re-boot the part after 1 second because AC is high and the shut-down will be perceived as a Fault

For this point, I don't understand why there are other battery-less designs (including the Beaglebone black when a battery isn't installed) that don't reboot after 1 second even if the AC is high when the PMIC is in OFF state. (I think this brings us back to the discussion of if AC detection is edge-sensitive, as the datasheet says, or level-sensitive as the datasheet says in between the lines.) I don't have a TPS65217 EVM, but to test, if the EVM is put into OFF state without a battery installed and AC input kept high, then the PMIC DOESN'T reboot after 1 second, then the reboot must be abnormal behavior, yes?