The part that is particularly interesting is that the firmware files are not loaded until immediately prior to u-boot handing off to the linux kernel. If differences between R19.3 and R21.x actually matter, it would have to be in the u-boot changes…the firmware files occur too late in the process to matter. One thing we do know is that u-boot itself was modified somewhere between R19.3 and R21.1.
It may be possible to copy the R19.3 u-boot.bin into an R21.x install (or vice versa) and see if behavior changes. I would not expect a bug-free boot this way, it is likely that some of those u-boot changes involved hardware setup and other software would depend on the changes (of course it would be good luck if the two versions of u-boot are interchangeable).
There is a supercap (C6D4,backup battery) in jetosn tk1 and it can retain charge for max an hour even if power cable is plugged out.
When it it charged, if you plugout and plug-in power cable, system will not boot. you have to explicitly press the ONKEY.
Once discharged, boot on plugin of power cable works. It is to retain clock time even after a plugout of power cable for atleast an hour.
You can get rid of this feature by HW change to get the super cap discharge fast.
Or in software (R21.x) , by removing this property in dts file ams,backup-battery-chargable.
Test Setup: I just took a board which was lying idle , flashed it and tested if plugging in and our power cable can boot the system consistently. And as Young said, let the supercap to discharge once before you try plugout-plugin
I suspect that if you make sure PMU’s “ON” signal is always active your board would start automatically when power is applied. That can be done my making the appropriate button always pressed or by soldering a wire to short it.
I know this is an older thread but I just wanted to confirm that the above solution does in fact solve the problem. C6D4 is located on the bottom of the board and very easy to remove. After removal the Jetson will power back on once power is reestablished
Removing C6D4 does not seem to work. We have a set of boards here and I tested on one. Short power interruptions would still cause the board to fail to boot up. You then need to press the power button to get the system to start. Shorting the power button does not seem to work either, as the button needs to be released and repressed for the system to start up.
Anyone know if there’s a way to get an official response on this? It’s sort of crazy that an embedded board would be designed in such a way that it doesn’t deal with power failure.
Well, I used AMS AS3722-BCTT-00 PMU (blank OTP) in my design and it does start automatically once power is applied if its ON pin is tied high.
But Jetson TK1 uses AMS AS3722-BCTT-09 PMU (custom programmed OTP) and one of the programmed OTP options is to invert the ON signal making it active-low. Therefore I suggested shorting the button on Jetson TK1 but I haven’t actually tried it myself.
I believe Jetson was originally intended as a developer test board, useful for proving the Tegra K1 and giving developers a software testing platform…Jetson just ended up being so successful that people started using it for an end production solution when it is really just a base reference design. For me, momentary power loss behavior just seems to be beyond the scope of a hardware/software demonstration which wasn’t originally intended as an actual hardware solution in production systems.
Regardless, the real solution is probably the onboard header J1A1. This is a standard front panel header for addition of external power on and power reset buttons (plus drive activity LED). A dedicated power loss/watchdog would normally be added here in anything requiring reliable power loss detection and reset. Implementing this would require only minimal/inexpensive hardware. If I were to do this I’d probably just add a mechanical relay which briefly holds down the reset (via capacitor/resistor for timing) when power is first applied.
I’d strongly suggest using a voltage monitor instead of mechanical relay because of relay’s contact bounce phenomena that might lead to multiple an unreliable resets of the system. Yes, you’ll have an RC network after it but why would you want to explicitly introduce a potential problem and then try to mitigate it? Voltage monitors are available in DIP packages so it would be easy to connect one to the Jetson TK1.
The mechanical relay was just an example to illustrate. The whole concept is simply to separate detection of need for reboot from the Jetson itself, using the J1A1 header as the interface to that detection circuit. Some people will need more intricate monitoring, e.g., brownouts versus short spikes of lost power versus long term power loss. It’s simply beyond the scope of an embedded reference module such as Jetson to add all of that when different people have different requirements.
I am facing OTP problem of AS3722. AS3722 is blank and brand new. Our situation is that we have developed our custom board based on tegra k1 and adapted AS3722 as a main pmu. Now we assembled the board and few pcs of samples ready on hand. AS3722 is exact same model with Nvidia Jetson Tegra K1 without OTP. As per cioma’s suggestion, we tried to connect with the AS3722 via I2C from Ardiuno Nano and UNO (we tried to communicate at 100kHz and 400kHz connection speed). VDD_GPIO_lv = 1.8V VSUP_GPIO = 3.7V Therm is grounded, AC_ok is grounded, LID is grounded, Onkey = High and Reset = High (High = 2.5V) There is no respond and occurring communication at all. Would you please help us to solve this issue if you managed this issue?
Bumping this to see if anyone has had success using the front panel pins to boot/reboot the Jetson successfully on their system. I’m currently using my Jetson in a robot and am looking for a way to have it power on every time the power switch for the robot is turned on, without using some “active” equipment like a relay, etc. My thought is to use something like an RC filter to perform this but my electrical background isn’t all that great so I’d love to get some input from others.