I2C Touchscreen Lockup: It Is Weak Pull-Ups, Not Linux

The Yocto-based touchscreen stopped accepting touches, but the visible freeze did not mean the full unit had stopped. Terminal commands could still change the displayed content, proving that the operating system, application, and display-output path remained active. The failed path began at touch acquisition and extended through the shared I2C bus. Weak 10 kΩ pull-ups produced a slow clock rising edge; replacing them with reviewed 4.7 kΩ values removed the repeatable lockup.

What Is the Frozen Screen Actually Telling You?

Start with the operator-visible symptom and separate display output from touch input. A screen that ignores touches may still be receiving and rendering new data. Treating both functions as one subsystem sends troubleshooting toward application crashes, display controllers, or full operating-system lockups before those conditions have been demonstrated.

Check: While touch is unresponsive, change visible screen content through a terminal command or another path that bypasses touch input. Proceed only after confirming whether display output and the operating system remain active.

How Do You Separate the Application from the Touch Driver?

Trace the event chain in its actual order: a touch controller detects contact, transfers data through I2C, the vendor-provided driver publishes an input event, and the application binds that event to a screen action. A responsive display proves only the output half of that chain. It does not prove that the touch controller, driver, or I2C transaction is healthy.

1. Leave the unit in the failed state; do not power-cycle it before collecting data.
2. Confirm that the operating system still accepts terminal commands.
3. Command a visible display change without using the touchscreen.
4. Inspect whether the application continues updating time, status, animation, or other independently changing content.
5. Test every device sharing the touch controller's I2C bus.

In this installation, the DS1307 RTC and touchscreen interface were the only two devices on the bus. Neither functioned after the lockup. That shared failure moves the diagnostic boundary below the application and individual device drivers. Retrying one touch transaction cannot correct a bus whose electrical state or attached-device state machine remains stuck.

Check: Confirm that non-touch application and display functions remain live while both I2C devices are unreachable. That combination identifies the shared bus as the next measurement point.

Which Log Entry Connects the RTC and Touchscreen Failures?

Review system logs around the first moment touch input stops, not only after a reboot. Intermittent I2C errors had appeared before the failure, and a corresponding RTC I2C error occurred when the touchscreen locked. The reported code may have been -5; retrieve the exact code and timestamp from the retained log rather than treating that recalled value as definitive.

Correlate timestamps before assigning cause. An old RTC error and a later frozen touchscreen may be unrelated; an error at the transition into the failed state is actionable. Preserve the pre-failure log window because a hard reset restores operation but can also discard volatile evidence.

Check: Reproduce one event with a timestamped touch failure and an I2C error from the other device in the same failure window.

How Can You Turn the Random Lockup into a Repeatable Test?

An intermittent field fault becomes diagnosable when the same symptom can be triggered on demand. Continuous operation eventually produced the lockup in-house, but waiting days for each iteration was inefficient. A shell script that repeatedly queried the I2C bus compressed the failure interval to about two seconds after its transaction pattern was tuned.

1. Record the normal query behavior and confirm that both the RTC and touch interface respond before stressing the bus.
2. Run repeated I2C queries while retaining timestamps in the system log.
3. Stop the test immediately after touch response and device communication fail.
4. Capture the log, bus state, and oscilloscope waveform before removing power.
5. Repeat the test on the unmodified circuit to prove that the stimulus produces the same failure signature.

The useful stress test reproduces the field symptom: touch becomes unresponsive, both I2C devices stop functioning, the operating system remains alive, and recovery requires a hard power reset. A test that merely generates transient I2C errors without creating that state is not yet reproducing the fault.

A stress script can also alter bus loading and transaction timing, so use it as a repeatable trigger rather than as proof of the electrical cause. The oscilloscope measurement supplies that proof.

Check: Demonstrate the complete failure signature repeatedly on the original 10 kΩ configuration before changing hardware.

What Does the Clock Rising Edge Reveal?

I2C lines use pull-up resistors to return the clock and data signals high after a device releases them. The pull-up resistance and total bus capacitance form an RC charging path. Higher resistance produces a slower rise for the same capacitance. If the signal reaches a receiver's valid-high threshold too late, a clock or data transition can be sampled incorrectly and leave attached devices in incompatible transaction states.

The schematic showed pull-ups, so connectivity alone looked correct. Their value was the defect: 10 kΩ produced a visibly slow clock rising edge under measurement. Similar product circuits used values between 2.7 kΩ and 4.7 kΩ, but copied circuits are comparison data, not a substitute for calculating and measuring the installed bus.

Probe at electrically meaningful points, including the controller and the farthest or most heavily loaded device when accessible. Inspect both clock and data lines during actual transactions. Measure the low level, high level, rise shape, ringing, and whether the signal crosses the receiver threshold with margin at the configured bus rate.

Check: Capture a slow rising edge on the original hardware under the same query load that triggers the lockup.

How Do You Select the Replacement Pull-Up?

Select pull-ups from the bus electrical limits, then validate the choice on hardware. The maximum useful resistance is constrained by the allowed rise time and total bus capacitance. The minimum resistance is constrained by the current that a device must sink while holding the line low. Supply voltage, device input capacitance, trace and cable capacitance, connector loading, leakage, bus speed, and every attached device affect the result.

Counting devices alone does not determine the resistor value; device count contributes through input capacitance and leakage. Read each device datasheet for its input limits and output-low sink capability, calculate the acceptable resistance window, and select a standard value inside that window. The chosen 4.7 kΩ value was calculated, checked with a design engineer, passed design review, and then compared empirically with other candidate values on the oscilloscope.

1. Inventory every controller, target device, trace, connector, and cable on the bus.
2. Obtain the permitted rise time, input thresholds, leakage, and output-low limits from the applicable device documentation.
3. Calculate the upper resistance limit from bus capacitance and rise-time requirements.
4. Calculate the lower resistance limit from supply voltage and the weakest permitted low-state sink capability.
5. Select a standard resistor value between those limits.
6. Install the candidate value and repeat waveform and stress testing at the actual operating conditions.

A lower resistance accelerates the rising edge but increases current whenever a line is low. The correct value is therefore not simply the smallest resistor that makes the waveform look sharp. The selected value must satisfy both the rising-edge requirement and every device's low-state electrical limit.

Check: With 4.7 kΩ installed, verify acceptable clock and data waveforms while all bus devices communicate under the repeatable stress load.

Why Did Software Bus Recovery Fail?

Once locked, neither the DS1307 RTC nor the touchscreen interface resumed operation through command-line bus-reset attempts. Sending nine high/low clock pulses also failed. A field software patch that detected the condition and reset I2C could not restore operation. Only a hard power reset recovered the installed system.

Clock pulses can release a target that is waiting to complete a partially received transfer, but they cannot clear every possible internal state. Recovery also fails if a device cannot interpret the pulses, holds a line in the wrong state, or requires its internal controller to be reinitialized by removal of power. Driver retries help with transient transaction failures; they do not repair an out-of-limit rising edge or guarantee recovery from a persistent device state-machine lock.

The hardware correction and software recovery serve different purposes. Correct pull-ups prevent the electrical condition that initiates the failure. Logging, retries, and fault detection improve diagnosis and handling of future transient errors, but they did not replace the resistor correction here.

Check: On an unmodified failed unit, document that command-line reset and nine clock pulses do not restore either device, then confirm that a hard power reset does.

How Do You Verify the Fix End to End?

Verification must attack the corrected bus more aggressively than normal operator use and must cover more than a responsive touch screen. The replacement removed the short stress-test failure, survived the script for several days, and ran across multiple units for about one week without another lockup. Units in field service had no recurrence after the pull-up change.

1. Record the installed pull-up value and capture post-change clock and data waveforms.
2. Run the same query script that locked the 10 kΩ circuit in about two seconds.
3. Continue the stress test for several days while collecting I2C errors and touch-response results.
4. Operate multiple modified units continuously for about one week.
5. Verify RTC communication, touch events, application response, and display updates throughout the run.
6. Review logs for I2C errors rather than accepting the absence of a visible freeze as the only pass criterion.
7. Power-cycle each unit and repeat normal startup and functional checks.

Final check: Pass the change only when the reviewed 4.7 kΩ configuration maintains valid bus waveforms, both I2C devices remain responsive, touch actions reach the application, display output continues updating, and the original stress script cannot reproduce the lockup during the extended run.

FAQ