You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At Google, we could want to use JTAG on chips in DEV lifecycle, running our production code. However, one unfortunate effect of enabling the JTAG strapping, is that the signals that share pins with JTAG are all seen as low / "0" by the chips, for as long as JTAG is active. One of those signals is the pwb_in input to the System Reset Controller, and since that signal is active low, it becomes impossible to debug any "ordinary" state of the system, which does not involve the System Reset Controller being in the process of counting down to reset something.
I propose that the levels seen by GPIO and various other IPs on the five inputs should instead be "frozen" at their previous value, when JTAG is enabled. Or if that presents an issue (e.g. with undefined state in case JTAG is enabled out of reset), that the inputs become fixed at high / "1" instead, as that is the inactive level for the keyboard and power button inputs in our use case.
The text was updated successfully, but these errors were encountered:
Description
At Google, we could want to use JTAG on chips in DEV lifecycle, running our production code. However, one unfortunate effect of enabling the JTAG strapping, is that the signals that share pins with JTAG are all seen as low / "0" by the chips, for as long as JTAG is active. One of those signals is the pwb_in input to the System Reset Controller, and since that signal is active low, it becomes impossible to debug any "ordinary" state of the system, which does not involve the System Reset Controller being in the process of counting down to reset something.
I propose that the levels seen by GPIO and various other IPs on the five inputs should instead be "frozen" at their previous value, when JTAG is enabled. Or if that presents an issue (e.g. with undefined state in case JTAG is enabled out of reset), that the inputs become fixed at high / "1" instead, as that is the inactive level for the keyboard and power button inputs in our use case.
The text was updated successfully, but these errors were encountered: