• TI Thinks Resolved

TPS65217: Spike of BATT pin

Guru 12130 points

Part Number: TPS65217

Hi,

Does the spike of the BAT pin as follows affect AC detection?

This spike is around 4V peak.

Best Regards,

Kuramochi

  • In reply to Jesse Caparangca:

    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?

  • In reply to Jesse Caparangca:

    Finally, if you haven't already, you may want to look at the "RTC-Only and RTC+DDR Mode" section of the "Linux Core Power Management User's Guide (v4.4)"

    processors.wiki.ti.com/.../Linux_Core_Power_Management_User's_Guide_(v4.4)

    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.

    Do you have a copy of the Linux Drivers for the TPS65217?
  • In reply to Brian Berner:

    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

  • In reply to Jesse Caparangca:

    Jesse,

    In your working projects, how does the system wake up from the 'OFF' state when LDO1 & SYS are shut off?

    Please excuse my naive question, but I don't often work with the full TPS65217 system so I need a baseline of what is considered 'good' in this state.
  • In reply to Brian Berner:

    Hi Brian,

    It's a totally valid question.

    We have two ways to wake up from OFF state: PB_IN pulled LOW by a push button in some projects, and by unplugging and plugging in the DC jack supply (PMIC AC input supply).

    In the case of unplugging and plugging in the DC jack supply, we still need to perform a clean software shutdown to make sure everything is unmounted properly then have the voltage rails sequentially shut down in order of the required shut down sequence. And also have all other peripherals turned off at the proper times.
  • In reply to Jesse Caparangca:

    Hi...i am a new user here. I am also experiencing an unintentional reboot 1 sec after SYS drops whenever we try to shutdown the system. Interrupt register reads AC status change (0x02) after this reboot so we suspect something with AC detection. BAT pins are floating and USB is tied to ground.
  • In reply to Ricky Terzis:

    Ricky,

    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.

    It is not a desired use case to have AC as the only power supply and not use a battery.

    There are 3 ways we mentioned to avoid this at stages in this e2e Thread:

    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
    2) If there is a power IC upstream from the TPS65217, cut off AC power at this device to ensure the TPS65217 is completely off and powered-down
    3) If you are new to using this design and have not yet created your own PCB, try using Case 3 in Figure 56 on page 77 of the datasheet which shows connecting 5V directly at BAT (instead of AC)

    Since the Push-Button (PB_IN) is only used to power-on from battery power (and you have no battery), I consider it to be a good thing that your system is "spontaneously" re-booting. If not, you would have a serious problem on your hands: an edge on AC would be required to turn on again, but AC is already high and no new edges are expected.
  • In reply to Brian Berner:

    Hi Brian,

    I'm wondering why would TI state in the datasheet that battery-less operation is completely fine but then disown it in the support forums when something goes wrong in a few cases? I'm sure there are thousands of TPS65217 based designs that are using battery-less use cases (Beaglebone black being one of them), but don't experience this reboot issue. I might of missed it, but I don't see anything in the datasheet discouraging the battery-less use case.

    And wasn't the SLEEP state (RTC-only mode) de-featured by TI a while back? I'm not completely sure about this, but somewhere in this forum someone mentioned this.


    Regards,
    Jesse
  • In reply to Jesse Caparangca:

    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.

  • In reply to Brian Berner:

    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