low-power-debug

Name: low-power-debug
Author: easyzoom

22stars2forks

How to install low-power-debug?

easyzoom/aix-skills/low-power-debug

$npx -y skills add easyzoom/aix-skills --skill low-power-debug

Installs into the current project.

Summary

Use when debugging embedded sleep, standby, deep sleep, wakeup, current consumption, clock gating, lost debug access, or low-power mode failures

Files · 1

View on GitHub

SKILL.md

1	# Low Power Debug
2
3	## Overview
4
5	Use this skill to debug low-power behavior by measuring current and wake sources before changing sleep configuration. Low-power bugs often involve board leakage, clocks, wake flags, debug settings, peripheral state, and firmware sequencing.
6
7	## When To Use
8
9	Use this skill when:
10
11	- Current consumption is too high or unexpectedly low.
12	- The device fails to enter sleep, cannot wake, wakes immediately, or loses debug access.
13	- The task involves sleep, stop, standby, deep sleep, retention RAM, wake pins, RTC, watchdog, clock gating, or PMIC sequencing.
14
15	Do not use this skill when the board cannot boot at all; establish basic boot first.
16
17	## First Questions
18
19	Ask for:
20
21	- Chip/board and intended low-power mode.
22	- Measured current, expected current, and measurement setup.
23	- Wake sources and whether wake flags are available.
24	- Debug probe attached or detached during measurement.
25	- Peripherals left enabled before sleep.
26	- Power rails, external devices, pull-ups, and board revision.
27
28	## Workflow
29
30	1. Confirm measurement validity.
31	Check meter range, sampling rate, burden voltage, shunt placement, rails included, and whether debugger/USB is attached.
32
33	1. Separate firmware from board leakage.
34	Measure baseline board state, external devices, pull-ups, LEDs, regulators, and sensors.
35
36	1. Confirm intended sleep mode.
37	Verify the actual mode entered, not just the API called.
38
39	1. Capture wake reason.
40	Read wake flags immediately after wake before clearing them.
41
42	1. Disable peripherals methodically.
43	Clocks, UART, ADC, timers, DMA, USB, radio, sensors, and pull configurations can dominate current.
44
45	1. Protect debug access.
46	Warn that deep sleep may disconnect SWD/JTAG. Use timed wake, GPIO heartbeat, or connect-under-reset recovery.
47
48	## Checks
49
50	- Debugger and semihosting disabled for current measurement.
51	- Unused GPIO configured to safe states.
52	- External pull-ups/pull-downs not causing leakage.
53	- Regulator and sensor quiescent currents accounted for.
54	- Wake pins polarity and pull state correct.
55	- RTC/LPTIM/watchdog clock source active if used.
56	- SRAM/retention domains configured intentionally.
57	- Interrupt flags cleared before sleep and read after wake.
58
59	## Verification
60
61	Before claiming progress:
62
63	- State measured current, expected current, mode, and measurement setup.
64	- State whether debugger/USB was connected.
65	- Report actual wake source or wake flag evidence.
66	- List peripherals and rails still enabled.
67	- State recovery method if debug access may be lost.
68
69	## Common Failures
70
71	- Measuring through USB while claiming battery current.
72	- Leaving the debugger attached and trusting sleep current.
73	- Clearing wake flags before reading them.
74	- Ignoring external sensors, pull-ups, LEDs, or regulators.
75	- Entering a shallower sleep mode than intended because a peripheral clock is active.
76
77	## Example
78
79	User:
80
81	```text
82	进入低功耗后电流还有 5mA，预期几十微安。
83	```
84
85	Agent:
86
87	1. Asks for mode, current setup, rails measured, debugger state, wake sources, and board peripherals.
88	1. Separates board leakage from MCU sleep current.
89	1. Checks enabled clocks, GPIO states, regulators, and wake flags before code changes.

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

low-power-debug

22stars2forks

View on GitHub

How to install low-power-debug?

easyzoom/aix-skills/low-power-debug

$npx -y skills add easyzoom/aix-skills --skill low-power-debug

Installs into the current project.

Summary

Use when debugging embedded sleep, standby, deep sleep, wakeup, current consumption, clock gating, lost debug access, or low-power mode failures

Files · 1

View on GitHub

SKILL.md

1	# Low Power Debug
2
3	## Overview
4
5	Use this skill to debug low-power behavior by measuring current and wake sources before changing sleep configuration. Low-power bugs often involve board leakage, clocks, wake flags, debug settings, peripheral state, and firmware sequencing.
6
7	## When To Use
8
9	Use this skill when:
10
11	- Current consumption is too high or unexpectedly low.
12	- The device fails to enter sleep, cannot wake, wakes immediately, or loses debug access.
13	- The task involves sleep, stop, standby, deep sleep, retention RAM, wake pins, RTC, watchdog, clock gating, or PMIC sequencing.
14
15	Do not use this skill when the board cannot boot at all; establish basic boot first.
16
17	## First Questions
18
19	Ask for:
20
21	- Chip/board and intended low-power mode.
22	- Measured current, expected current, and measurement setup.
23	- Wake sources and whether wake flags are available.
24	- Debug probe attached or detached during measurement.
25	- Peripherals left enabled before sleep.
26	- Power rails, external devices, pull-ups, and board revision.
27
28	## Workflow
29
30	1. Confirm measurement validity.
31	Check meter range, sampling rate, burden voltage, shunt placement, rails included, and whether debugger/USB is attached.
32
33	1. Separate firmware from board leakage.
34	Measure baseline board state, external devices, pull-ups, LEDs, regulators, and sensors.
35
36	1. Confirm intended sleep mode.
37	Verify the actual mode entered, not just the API called.
38
39	1. Capture wake reason.
40	Read wake flags immediately after wake before clearing them.
41
42	1. Disable peripherals methodically.
43	Clocks, UART, ADC, timers, DMA, USB, radio, sensors, and pull configurations can dominate current.
44
45	1. Protect debug access.
46	Warn that deep sleep may disconnect SWD/JTAG. Use timed wake, GPIO heartbeat, or connect-under-reset recovery.
47
48	## Checks
49
50	- Debugger and semihosting disabled for current measurement.
51	- Unused GPIO configured to safe states.
52	- External pull-ups/pull-downs not causing leakage.
53	- Regulator and sensor quiescent currents accounted for.
54	- Wake pins polarity and pull state correct.
55	- RTC/LPTIM/watchdog clock source active if used.
56	- SRAM/retention domains configured intentionally.
57	- Interrupt flags cleared before sleep and read after wake.
58
59	## Verification
60
61	Before claiming progress:
62
63	- State measured current, expected current, mode, and measurement setup.
64	- State whether debugger/USB was connected.
65	- Report actual wake source or wake flag evidence.
66	- List peripherals and rails still enabled.
67	- State recovery method if debug access may be lost.
68
69	## Common Failures
70
71	- Measuring through USB while claiming battery current.
72	- Leaving the debugger attached and trusting sleep current.
73	- Clearing wake flags before reading them.
74	- Ignoring external sensors, pull-ups, LEDs, or regulators.
75	- Entering a shallower sleep mode than intended because a peripheral clock is active.
76
77	## Example
78
79	User:
80
81	```text
82	进入低功耗后电流还有 5mA，预期几十微安。
83	```
84
85	Agent:
86
87	1. Asks for mode, current setup, rails measured, debugger state, wake sources, and board peripherals.
88	1. Separates board leakage from MCU sleep current.
89	1. Checks enabled clocks, GPIO states, regulators, and wake flags before code changes.

People who liked this also viewed

6 picks

Type