Part Number: TPS65217
Does the spike of the BAT pin as follows affect AC detection?
This spike is around 4V peak.
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 Brian Berner:
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?
In reply to Ricky Terzis:
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.
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.