hardware-interface-debug

Name: hardware-interface-debug
Author: easyzoom

22stars2forks

How to install hardware-interface-debug?

easyzoom/aix-skills/hardware-interface-debug

$npx -y skills add easyzoom/aix-skills --skill hardware-interface-debug

Installs into the current project.

Summary

Use when debugging embedded board-level power, reset, clock, pin, connector, signal integrity, logic analyzer, oscilloscope, or hardware interface issues

Files · 1

View on GitHub

SKILL.md

1	# Hardware Interface Debug
2
3	## Overview
4
5	Use this skill when firmware symptoms may actually come from board-level signals. Verify power, reset, clocks, pin mapping, voltage levels, and measured waveforms before treating the issue as a software bug.
6
7	## When To Use
8
9	Use this skill when:
10
11	- The issue involves power rails, reset, crystals, boot pins, connectors, level shifters, pull-ups, or signal integrity.
12	- A peripheral or debug interface has no signal, wrong voltage, ringing, stuck line, or intermittent behavior.
13	- The user has a schematic, board photo, oscilloscope capture, logic analyzer trace, or pinout question.
14
15	Do not use this skill when the hardware path has already been verified and the issue is clearly inside firmware logic.
16
17	## First Questions
18
19	Ask for:
20
21	- Board/chip, revision, and affected interface.
22	- Schematic snippet or pin mapping if available.
23	- Expected signal and observed measurement.
24	- Measurement tool: multimeter, oscilloscope, logic analyzer, current probe.
25	- Power source and voltage levels.
26	- Whether the issue is reproducible across boards.
27
28	## Workflow
29
30	1. Start with power and ground.
31	Confirm rail voltage, sequencing, ripple, current limit, ground reference, and target voltage for debug probes.
32
33	1. Check reset and clock.
34	Verify reset release, boot strap states, oscillator startup, clock output, and brownout/watchdog conditions.
35
36	1. Trace the signal path.
37	Map MCU pin, package pin, board net, connector, level shifter, external device, and pull components.
38
39	1. Measure at the right points.
40	Compare near-MCU and near-peripheral signals to catch level shifter, connector, or routing issues.
41
42	1. Compare against firmware configuration.
43	Pin mux, open-drain/push-pull, drive strength, alternate function, and analog mode must match the hardware.
44
45	1. Avoid destructive experiments.
46	Do not short pins, force rails, remove protections, or bypass regulators without explicit user approval.
47
48	## Signal Checks
49
50	- Voltage level matches both devices.
51	- Ground reference is shared.
52	- Pull-up/down values are appropriate.
53	- Rise/fall time fits bus speed.
54	- No two outputs fight on the same net.
55	- Boot strap resistors match intended mode.
56	- Debug pins are not overloaded by external circuits.
57	- Reset pulse width and polarity match datasheet.
58
59	## Measurement Guidance
60
61	- Use a multimeter for static rails and reset state.
62	- Use an oscilloscope for clocks, reset edges, ripple, ringing, and analog behavior.
63	- Use a logic analyzer for decoded UART/SPI/I2C timing.
64	- Use current-limited bench supply for bring-up when safe.
65	- Capture before and after reset or transaction start when timing matters.
66
67	## Verification
68
69	Before claiming hardware evidence:
70
71	- State measurement location, tool, voltage/time scale when relevant, and observed value.
72	- Map the measured net to MCU pin and external device pin.
73	- State whether the measurement supports or contradicts the firmware assumption.
74	- List unsafe hardware actions avoided or awaiting approval.
75
76	## Common Failures
77
78	- Measuring only at the connector and not at the MCU pin.
79	- Forgetting common ground for UART/debug adapters.
80	- Treating an open-drain bus as push-pull.
81	- Ignoring boot strap resistors or reset timing.
82	- Debugging firmware while the rail is current-limited or brownout-resetting.
83
84	## Example
85
86	User:
87
88	```text
89	SPI 读出来全是 0xFF，代码看起来没问题。
90	```
91
92	Agent:
93
94	1. Asks for schematic, pins, voltage, SPI mode, and logic analyzer capture.
95	1. Checks CS/SCK/MOSI/MISO near both MCU and slave.
96	1. Verifies MISO is not floating, voltage levels match, and CS timing reaches the device.

People who liked this also viewed

6 picks

Type

azure-diagnosticsDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deploySkillsJul 2026472k1.3k
systematic-debuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesSkillsJul 2026197k259k
safe-debugRigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training SkillsMay 2026161k507
explore-runRigor Improve / Rigor Explore run leaf skill for bounded exploratory evidence in deep learning research repositories. Use when the researcher explicitly authorizes exploratory runs such as small-subseSkillsMay 2026161k507
minimal-run-and-auditRigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation SkillsMay 2026161k507
insforge-debugUse when diagnosing problems in an InsForge project — reactive failures (SDK error object, HTTP 4xx/5xx, gateway timeout 502/503/504, edge function failure or timeout, login/OAuth/auth errors, RLS denSkillsJul 202618k31

hardware-interface-debug

22stars2forks

View on GitHub

How to install hardware-interface-debug?

easyzoom/aix-skills/hardware-interface-debug

$npx -y skills add easyzoom/aix-skills --skill hardware-interface-debug

Installs into the current project.

Summary

Use when debugging embedded board-level power, reset, clock, pin, connector, signal integrity, logic analyzer, oscilloscope, or hardware interface issues

Files · 1

View on GitHub

SKILL.md

1	# Hardware Interface Debug
2
3	## Overview
4
5	Use this skill when firmware symptoms may actually come from board-level signals. Verify power, reset, clocks, pin mapping, voltage levels, and measured waveforms before treating the issue as a software bug.
6
7	## When To Use
8
9	Use this skill when:
10
11	- The issue involves power rails, reset, crystals, boot pins, connectors, level shifters, pull-ups, or signal integrity.
12	- A peripheral or debug interface has no signal, wrong voltage, ringing, stuck line, or intermittent behavior.
13	- The user has a schematic, board photo, oscilloscope capture, logic analyzer trace, or pinout question.
14
15	Do not use this skill when the hardware path has already been verified and the issue is clearly inside firmware logic.
16
17	## First Questions
18
19	Ask for:
20
21	- Board/chip, revision, and affected interface.
22	- Schematic snippet or pin mapping if available.
23	- Expected signal and observed measurement.
24	- Measurement tool: multimeter, oscilloscope, logic analyzer, current probe.
25	- Power source and voltage levels.
26	- Whether the issue is reproducible across boards.
27
28	## Workflow
29
30	1. Start with power and ground.
31	Confirm rail voltage, sequencing, ripple, current limit, ground reference, and target voltage for debug probes.
32
33	1. Check reset and clock.
34	Verify reset release, boot strap states, oscillator startup, clock output, and brownout/watchdog conditions.
35
36	1. Trace the signal path.
37	Map MCU pin, package pin, board net, connector, level shifter, external device, and pull components.
38
39	1. Measure at the right points.
40	Compare near-MCU and near-peripheral signals to catch level shifter, connector, or routing issues.
41
42	1. Compare against firmware configuration.
43	Pin mux, open-drain/push-pull, drive strength, alternate function, and analog mode must match the hardware.
44
45	1. Avoid destructive experiments.
46	Do not short pins, force rails, remove protections, or bypass regulators without explicit user approval.
47
48	## Signal Checks
49
50	- Voltage level matches both devices.
51	- Ground reference is shared.
52	- Pull-up/down values are appropriate.
53	- Rise/fall time fits bus speed.
54	- No two outputs fight on the same net.
55	- Boot strap resistors match intended mode.
56	- Debug pins are not overloaded by external circuits.
57	- Reset pulse width and polarity match datasheet.
58
59	## Measurement Guidance
60
61	- Use a multimeter for static rails and reset state.
62	- Use an oscilloscope for clocks, reset edges, ripple, ringing, and analog behavior.
63	- Use a logic analyzer for decoded UART/SPI/I2C timing.
64	- Use current-limited bench supply for bring-up when safe.
65	- Capture before and after reset or transaction start when timing matters.
66
67	## Verification
68
69	Before claiming hardware evidence:
70
71	- State measurement location, tool, voltage/time scale when relevant, and observed value.
72	- Map the measured net to MCU pin and external device pin.
73	- State whether the measurement supports or contradicts the firmware assumption.
74	- List unsafe hardware actions avoided or awaiting approval.
75
76	## Common Failures
77
78	- Measuring only at the connector and not at the MCU pin.
79	- Forgetting common ground for UART/debug adapters.
80	- Treating an open-drain bus as push-pull.
81	- Ignoring boot strap resistors or reset timing.
82	- Debugging firmware while the rail is current-limited or brownout-resetting.
83
84	## Example
85
86	User:
87
88	```text
89	SPI 读出来全是 0xFF，代码看起来没问题。
90	```
91
92	Agent:
93
94	1. Asks for schematic, pins, voltage, SPI mode, and logic analyzer capture.
95	1. Checks CS/SCK/MOSI/MISO near both MCU and slave.
96	1. Verifies MISO is not floating, voltage levels match, and CS timing reaches the device.

People who liked this also viewed

6 picks

Type