We have a TK1 based system that boots to a non-Ubuntu GUI with V1.2A TK1 SOMs. Specifically, Yocto build from your template, Using Zeus. Nvidia kernel 3.10 with patches, including the GPIO7 ‘fix’. On a number of systems with this build and up to build 3.1.0RCf, we have experienced system power shutdowns just prior to the GUI coming active, that is, the display spits out the usual bootup log scroll right up to login prompt, blanks, and then the system shuts down. Please note this happens very infrequently across a population of maybe 6 systems, and has never been experienced under the bootup to Ubuntu desktop under any preceding BSP generations.
Since the SOM is the sole driver of the POWER_ENABLE_MOCI signal which commands the host power system to shut off, it appeared to be the prime suspect. Our host board (SOM carrier) implements a 120msec masking filter on the POWER_ENABLE_MOCI signal to tolerate the 60msec software reset pulse per Question # 24926 in this forum. This has worked very well since being implemented and we’ve never experienced shutdowns on software or pushbutton resets of the SOM.
Taking one system which experienced self-shutdown several times in a short period, a slight modification was made to gate off the POWER_ENABLE_MOCI signal from the host board power system. The modification was not directly applied to the signal itself in order to preserve the electrical conditions present on POWER_ENABLE_MOCI. We then set up some automation that would power cycle the unit and trigger on any falling transitions of POWER_ENABLE_MOCI. Once triggered, the power cycle timer was halted so the system is left powered after the POWER_ENABLE_MOCI falling edge took place. A scope was also connected and triggered by the falling edge of POWER_ENABLE_MOCI. After days of power cycles, we were fortunate enough to capture a single shutdown event, the scope trace of which I have attached here.
The lower trace is POWER_ENABLE_MOCI from the SOM. Two questions are raised here; if this was a software reset, why is the pulse longer than the claimed 60msec described in Q/A 24926? If this was a deliberate shutdown request, why does the pulse return high after 250msec? The system remained live and responsive despite not having executed a full power-cycle restart. On actual commanded shutdowns, POWER_ENABLE_MOCI remains low and the system is unresponsive if the power remains active.
The client’s GUI did come up on display and was responsive to touch, indicating the USB subsystem was initialized and active, and the client’s application had started up correctly and was running stably (we let the system sit powered for a couple days and it remained responsive). What are the possible mechanisms in the circuitry of the TK1 SOM that could produce a rogue 250msec low pulse? The description provided in Q/A 24926 by Toradex seems to imply a hardware determined maximum pulse width of 60msec.
For your interest, the upper trace is the control signal from the power cycle timer; this signal is not used in place of the POWER_ENABLE_MOCI but actuates a button input on the power controller. It asserts low for 7-seconds to trip a 6-second power-down timer. It runs on a 50-second cycle, long enough to let the system boot up to the client GUI. Once off, it powers the system up 42 seconds later to ensure local rails discharge substantially and any DRAM data gets scrubbed. In the trace, the short low transition coincident with the lower trace (POWER_ENABLE_MOCI ) falling edge simply reflects the timer gating function once a trigger occurs.