Couple questions about power

On the TK1, there was a cap that could be removed to get the board to boot as soon as it was plugged in. Is there anything similar for the TX1? We’re using the supplied carrier board, if that’s helpful.

On our mobile platform, we occasionally get voltage dips. To fight this, we’ve built a simple circuit with a large supercap. It uses a schottky diode to isolate the supercap when the power is good (and charges it through a high wattage resistor) and then when power drops, it should switch to the cap to hold the voltage up. Most everything works, but the problem we’re seeing is if we unplug the power supply and run strictly off the supercap, the TX1 board powers off. We’ve tried some decoupling caps across the TX1 power input and they haven’t helped. We’ve tried to scope the power in to look for transients and there aren’t any that we can see. Any ideas on what might be happening?

Hi,

Where did you put your supercap and how big is it ?

If you look at the TX1 power sequence you can see that you need to have the input just after the Jack to have the VIN_PWR_BAD signal high.

With a little math if you have a 20mF supercap under 12V you have 1.44 Joule aka 0.22mWh availables…
If the board consumes 5W you can power it for only 2 minutes…
But I guess you’ve a bigger one and the problem should be in the understanding of the input mechanism done on the carrier ;)

Look at page 27 of the reference schematic and try to understand which impacts your customization has on it.

Thanks for the pointer - I’ll review the schematic page you’re talking about. Right now the input from the supercap is going directly into the power jack, isolated from the normal input using a schottky diode. It seems to work in almost every case, except for when the main input voltage is cut completely. But obviously we’re missing something so off to the schematics.

And yes, we’re using something “slightly” larger than 20mF : http://elcodis.com/parts/1983503/BMOD0058_E016_B02.html.

okay supercap is out of concern :D.

Could you publish the transcient measurements you have done with the scope ?
Maybe the Jetson needs a big spike of current in transcient that the supercap or Schottky can’t handle…And you have that Shottky on both inputs (Supercaps + main supply) to do a physical OR ? I guess you’ve already checked it…

Could you try to power up the Jetson with a lab supply at 6-7V please ? (I don’t have the Jetson TX1…European delight ^^).

Edit : I suspect that Q31 is being saturated by your design if the ripple of your input is more than Vth min of that transistor (ie 0.8V) . Maybe the TX1 module has an internal circuitry or software parameter that make it not powering for a time if the signal VDD_PWR_BAD_L is asserted by Q31…

Regards,
Ale

I’ll double-check the layout of the circuit - that’s a good point.

I don’t have a picture of the ripple handy, but from memory it was ~4V dip followed by some smaller ripples. This happened over a short time (<1uSec, not sure if my memory is right here), so not a long time but maybe enough to trigger what you’re talking about.

We’ve had luck keeping the Jetson running on <6-7V, but I’m not sure about powering it up. We’ll do some more testing and see.

For sure 1us is nothing… but your (our now because I’m really interested in knowing why you’re facing this ;)) problem is to know how TX1 module/proc reacts from changes on pins related to the power sequence…

That is the only lead I see if you are confident about your caps and layout.

To easily test it you could solder a strap on either R273 or R274 to ground to make VIN_PWR_BAD always on high state ;).

Finally had a chance to get back to this. As a quick test we removed R273, thinking that would prevent Q31 from being influenced by the 19V power in. It didn’t change anything - we’re still having problems when disconnecting the battery and switching to the supercap.

I’m stumped at this point.

This may be related to a brick removal circuit on the devkit reference carrier board that detects a change in the input voltage and will initiate a controlled shutdown when it trips so that the Tegra rails are sequenced down appropriately. When running from a battery with a reasonable output resistance, transient loads could trip the circuit. There are a few possible options you could try at your own risk:

  1. Disable the circuit by removing resistor R93. However, note that the system needs to be shutdown properly from the power button before removing the battery or brick (i.e. don’t yank the power while the system is on).

  2. The sensitivity of the circuit can be reduced by adding a 4.7uF 35v ceramic cap in parallel with R105 and change C49 (0603) to 1uF 25v or greater.

We took approach #2 and things look a whole lot better. There’s more testing to do but so far it is stable through all the testing we’ve done. Thanks for the help!

Any advice on an approach to getting the board to boot as soon as power is applied?

Hi,

Nice to hear, I was close but dusty got it :D.

At this point, when you apply the power jack you have to press the power button ?

When using the reference devkit, you’ll likely need to stick with the POWER_BTN press. I believe if the CHARGER_PRSNT pin A49 is grounded, the PMIC will initiate a power on when it gets powered. However there’s been an issue recently which is pointing towards the CHARGER_PRSNT/ACOK power on method not being consistent. Delaying a toggle on POWER_BTN or delaying the pull down of CHARGER_PRSNT/ACOK up to 1 second after applying AC/DC power should be more reliable and consistent.

More realistic would be to use a voltage supervisor IC to insure a valid input voltage and produce a delayed output, that output could trigger a 555 one-shot with its output connected to the gate of an NFET with the NFET drain connected to the POWER_BTN signal (source grounded). However this approach would likely require modifications to the reference carrier design.

OK, that makes sense (or at least will once I get a chance to digest it a bit more). We’ll debate among ourselves how much of a downside it would be to have to hit the power button versus trying an external circuit to do it for us. Thanks for the info - I mostly wanted to make sure it wasn’t something simple I was overlooking.

What are the consequences for using option 1 in an embedded application without turning off the board separately? We are using the TX1 with reference Carrier in an FRC robot, and had to remove resistor R93 to get it to boot off our power supply (12V, 2A). The board is running an OpenCV app with some network communication, but doesn’t write to disk.

If option 1 will potentially pose an issue for our use case, is there an alternative to option 2 that doesn’t require playing around with tiny 0402 capacitors?

You risk data corruption if you disconnect power while the TX1 is still running but if you’re confidant that your app doesn’t write or read to disk then you’re probably fine.