s32debugger-flash-programming
Route S32Debugger flash requests to the correct specialized workflow. Use this whenever the user wants to flash, program, write, erase, verify, dump, or inspect flash contents, or wants to program an
SKILL.mdskills/s32debugger/s32debugger-flash-programming/SKILL.md
GitHubS32Debugger Flash Programming
Route flash requests to the correct specialized S32Debugger workflow. This
skill classifies flash-only versus debug-from-flash intent, checks whether the
required live startup/probe context already exists, and preserves the key
behavioral difference between flows that end with fl_close and flows that
stay open for same-session debugging.
When to use
Use this skill when:
- The user asks to flash, program, write, erase, verify, dump, or inspect flash contents through S32Debugger.
- The user wants to program an image and might also want to continue debugging from flash in the same session.
- The request needs routing before the flash leaf workflow is chosen.
Do not use this skill for:
- Detailed execution of an already classified flash-only request; use
s32debugger-flash-only-operations. - Detailed execution of an already classified same-session debug-from-flash
request; use
s32debugger-debug-from-flash.
Quickstart
1. Mandatory reference read
Before using this skill, read:
references/authoring-procedure.mdreferences/examples.md
Do not continue until those files have been reviewed.
2. Classify the flash intent first
Scenario A: flash-only operation
Scenario B: flash now, then continue debugging from flash in the same session
Rule: keep end-with-fl_close and stay-open-for-debug clearly separated
3. Check whether required startup context already exists
Need: GTA before GDB, GDB with Python support, probe/session connection,
valid bareboard init script for the flash path
4. Route to the correct leaf workflow
Flash-only: s32debugger-flash-only-operations
Debug-from-flash: s32debugger-debug-from-flash
Guardrails
Mandatory reference rule
- Read the listed reference files before selecting a branch, generating output, or producing the final answer.
- Treat the references as part of the skill, not as optional supplemental notes. Scope
- Route flash requests only; do not blend the two leaf flows.
- Preserve the difference between a session that ends with
fl_closeand one that remains open for post-flash symbolic debug. - Confirm whether required GDB/GTA/probe context already exists instead of pretending flash programming is always a zero-startup path.
- Defer low-level probe connection, init-script selection, and
board_init()/core_init()mechanics tos32debugger-connect-gdb-to-s32-debug-probe.
Destructive actions
- Default to routing and classification rather than executing the flash leaf flow here.
- Do not merge flash-only and debug-from-flash into one vague sequence.
- Do not recommend
fl_closefor same-session debug-from-flash intent.
Refuse-and-escalate
- If the request is ambiguous about whether the session should end or remain open for debug, ask that specific question before routing.
- If startup/probe context is missing, say so explicitly instead of implying the leaf skill can start from nowhere.
- If a matching symbol file is required for debug-from-flash but not provided, treat that as a blocker for the debug-from-flash route.
- If the user really needs the low-level GDB connection procedure, hand off to
s32debugger-connect-gdb-to-s32-debug-probe.
Do
- Use
s32flash.pyexpectations as the shared flash substrate. - Require a valid bareboard init script, not an attach script.
- Ask only for the smallest missing detail that blocks scenario classification.
Do not
- Use one blended flow for both scenarios.
- Skip
fl_closefor flash-only work. - Use debug-from-flash continuation for generic erase, verify, read, or dump operations.
Validation loop
- Confirm the required reference files were reviewed before executing the workflow or finalizing the answer.
- Confirm the request is classified as flash-only or debug-from-flash.
- Verify the required startup context is checked: GTA before GDB, Python-capable GDB, probe/session connection, and valid bareboard init path.
- Verify the chosen downstream skill matches the intended end state: close the flash session or keep the same GDB session open.
- Verify any required artifacts are identified: image/binary/ELF and matching symbol file when debug-from-flash is requested.
- Verify no low-level probe connection procedure is being restated here.
- Return the classified scenario, chosen downstream skill, context readiness, intended end state, key next step, and any missing blocker.
Out of scope
- Executing both flash leaf behaviors inside one blended skill body.
- Pretending required GDB/GTA/probe context already exists when it does not.
- Replacing the low-level probe connection skill.
- Guessing the user intent when the distinction between close-and-stop and continue-debugging is still unresolved.
See Also
references/authoring-procedure.md- scenario classification, shared prerequisites, and routing logic.references/examples.md- quick routing examples, anti-patterns, and response cues.- Related skills:
s32debugger-flash-only-operations,s32debugger-debug-from-flash,s32debugger-connect-gdb-to-s32-debug-probe,s32debugger-error-resolution