S32FlashTool Write RCON/EEPROM Hex Data

Write a hexadecimal byte string into the RCON/EEPROM region on a supported NXP S32 target.

This skill supports two execution modes:

• CLI mode using:
  • the cli_build_<op> + cli_execute actions
  • typically via cli_build_fprogram (hex string written to a temp file, passed via file_path)
• GUI mode using S32FlashTool GUI over RPC:
  • the matching gui_* action
  • with fullConfigUploadHexToRcon followed by initialization and flash.clickUploadFileToDevice

This skill is operation-focused:

• it explains what the RCON write operation needs
• how to choose GUI vs CLI
• how to execute the write in each mode
• how to validate the outcome
• how to handle destructive-operation confirmation safely

When to use

Use this skill when the user wants to:

• write boot configuration bytes into RCON
• update EEPROM/RCON contents as a hex string
• modify RCON bytes at a start address
• program boot-source configuration bytes such as XSPI boot settings into RCON
• trigger the S32FlashTool GUI RCON-write workflow through RPC

When not to use

Do not use this skill for:

• file-based flash programming -> use s32flashtool-upload-file-to-flash
• reading RCON/EEPROM -> use s32flashtool-read-rcon
• reading flash contents -> use s32flashtool-read-flash
• erasing flash only -> use s32flashtool-erase-flash
• executing a binary from SRAM -> use s32flashtool-sram
• identifying the processor -> use s32flashtool-read-mcuid

Shared references

• Apply shared rules from s32flashtool-agent-rules-minimal/SKILL.md.
• Use s32flashtool-workflow-index/SKILL.md to select the correct operation skill.

Quickstart

1. Select mode see ## Mode selection policy
2. Gather inputs see ## Required inputs (use discovery calls from ## Preconditions)
3. Preview the operation CLI: preview_only=true; GUI: show fullConfigUploadHexToRcon payload
4. Obtain confirmation phrase "yes, write RCON" see ## Guardrails (Destructive actions)
5. Execute references/CLI.md or references/GUI.md
6. Validate see ## Validation loop (readback strongly recommended)

Mode selection policy

Choose execution mode as follows:

1. If the user explicitly asks for GUI, window, RPC, or S32FlashTool GUI, use the GUI/RPC flow.
2. If the user explicitly asks for CLI, command line, shell, or requests a command, use the CLI flow.
3. If the user does not specify GUI or CLI:
   • continue using GUI/RPC if a working GUI/RPC session is already in progress
   • otherwise, ask whether GUI or CLI is preferred
4. If the user previously established a working GUI RPC session and continues issuing GUI-style requests, continue with RPC.
5. Do not silently switch from GUI to CLI or from CLI to GUI.
6. If the requested behavior is only possible through the other mode, explain the fallback before doing it.

Preconditions

Before writing RCON/EEPROM, ensure:

1. The S32FlashTool installation folder is known.
2. The target binary exists and matches the processor family.
3. The selected algorithm is the RCON algorithm, typically RCON.bin.
4. The communication interface is known:
   • uart
   • can
   • ethernet
5. The communication endpoint is known.
6. The board is connected and powered.
7. The board is in serial boot mode for S32FlashTool communication.
8. The start address and hex string are known.
9. If a different target/algorithm was used previously, a board reset / restart into serial boot may be necessary.
10. The user has explicitly confirmed the destructive write action.

Recommended preparation

Use concrete discovery tool calls instead of guessing. The following hints map each precondition to a tool call:

• List candidate target binaries:
  • list_platform_files action (bin_type="target").
• List candidate flash/RCON algorithms (RCON algorithm is normally RCON.bin):
  • list_platform_files action (bin_type="flash").
• Confirm device / algorithm / interface support before any hardware-specific action:
  • list_platform_files action (bin_type="supported") and read the matching supported_<platform>_devices.txt.
• Inspect board-specific examples and PDFs for RCON layout / boot-configuration notes:
  • list_platform_files action (bin_type="blob")
  • list_platform_files action (bin_type="example_pdf").
• Discover available communication ports if the port is unknown:
  • the cli_build_<op> + cli_execute actions with list_ports=true.
• Identify the processor on the connected board when family is uncertain:
  • apply skill s32flashtool-read-mcuid (uses cli_build_mcuid + cli_execute).
• Capture the current RCON content before modifying it:
  • apply skill s32flashtool-read-rcon over the same range.

Do not invent values for target, algorithm, port, addr, or hex_string. Use the discovery calls above, board/family RCON layout documentation, or ask the user.

Required inputs

Collect or confirm the following. These are user-level inputs (what the user must supply); each mode transforms them into mode-specific tool arguments.

• s32flashtool_folder
• target
• algorithm (normally RCON.bin)
• interface
• port
• addr
• hex_string -- the hexadecimal byte string to write. This is NOT a direct argument of the cli_build_<op> + cli_execute actions (no such parameter exists on the wrapper). It is transformed per mode:
  • CLI: written to a temporary file, then passed via file_path via cli_build_fprogram. See references/CLI.md.
  • GUI / RPC: passed as the hexString field of the fullConfigUploadHexToRcon payload. See references/GUI.md.

Optional inputs

• size if the CLI form needs it explicitly
• extra_args

Input rules

• Do not guess the target binary.
• Do not guess the RCON algorithm path.
• Do not guess the COM port.
• Use absolute file paths where relevant.
• Preserve the user's intended start address exactly.
• Preserve the hex data exactly; do not reinterpret byte order unless the user explicitly asks.
• RCON/EEPROM size is typically 24 bytes total; addr should be within the valid RCON range and the hex string length aligned with the intended byte count. Do not assume writes larger than 24 bytes are valid unless target documentation proves otherwise.
• Prefer reading the existing RCON content first when modifying only part of the structure.
• Do not claim semantic interpretation of RCON bytes unless supported by board-specific documentation or readback evidence.
• For GUI workflows, numeric strings may be normalized by the GUI. Treat that as normal unless the semantic value changed incorrectly.

GUI / RPC flow

See references/GUI.md for the full GUI / RPC flow, payloads, and example sequences.

CLI flow

See references/CLI.md for the full CLI flow, parameters, and example MCP calls.

Validation loop

Readback validation is strongly recommended because RCON changes can alter boot behavior even when the write operation reports success.

After writing RCON/EEPROM, validation may include:

• reading back the modified RCON bytes
• confirming the EEPROM data matches the intended hex string
• checking whether boot behavior changes as expected
• comparing before/after RCON contents

Practical validation examples

• use s32flashtool-read-rcon to read back the modified region
• read the exact modified byte range immediately after programming
• read all 24 bytes when practical and compare them to the intended result
• validate expected boot mode behavior on the board
• if boot-source bytes were changed, remind the user that a restart may be required before testing the new boot path

Failure modes

Recognize these failures from tool output and respond accordingly. Never auto-retry a destructive operation. RCON write is the highest-stakes operation in this pack: an incorrect RCON value can prevent the board from booting from any source, including serial boot, and in that state the board may not be recoverable in software. On any failure, report the exact tool output before proposing next steps.

#	Failure	Symptom	Interpretation	Response
1	User-aborted write (GUI)	flash.clickUploadFileToDevice returns OK but GUI dialog cancelled or reports aborted	RPC click dispatched; operation did not complete	Report as user-cancelled; ask whether to retry. Do not claim success.
2	Target / algorithm mismatch	Algorithm does not match device; RCON not accessible; identification-related error at start	Wrong target and/or algorithm for the connected board	Stop. Re-run list_platform_files action (bin_type="supported") and consult supported_<platform>_devices.txt. If family uncertain, apply s32flashtool-read-mcuid first. Do not guess a new algorithm.
3	Invalid hex value / bad boot-config encoding	Odd number of hex digits, non-hex characters, wrong length for the RCON layout; or a syntactically valid but semantically invalid boot configuration (reserved bit pattern, undefined boot source, unsupported mode)	Input did not pass basic tool validation, or encodes an unsupported/reserved configuration	Do not proceed with the write. Ask the user to source the intended hex value from the board or family RCON layout documentation, not from inference. Never suggest a "reasonable default" for RCON; there is no reasonable default.
4	Oversize write / out-of-range address	Tool reports the write exceeds RCON/EEPROM size or the start address is out of range	addr + hex-string length out of the valid RCON range (typically 24 bytes)	Do not silently clip. Confirm the RCON size/range from installed documentation. Ask the user to restate addr/hex_string within a valid range.
5	Missing initialization (GUI/RPC)	flash.clickUploadFileToDevice fails; destination reported as not initialized	init.clickLaunchInitialization was skipped or failed for EEPROM (RCON)	Call init.clickLaunchInitialization before retrying. If init itself fails, treat as row 2 or row 6.
6	Communication / boot-mode / path errors	Port not open; no response; file-not-found on target/algorithm paths	Wrong port, board not in serial boot, previous session used a different target/algo, or bad paths	Verify target/algorithm paths, interface, port, addr, hex-string length/content, boot mode. Confirm serial boot mode. If a different algorithm ran previously, ask the user to reset the board into serial boot.
7	GUI/RPC unavailable	hello fails or RPC endpoint unreachable	GUI not running or RPC disabled	Do not launch a second GUI blindly; follow the launch procedure in s32flashtool-rpc-api. Explain unavailability and ask whether CLI fallback is acceptable.
8	CLI surface insufficient for hex write	Installed CLI lacks a documented path to write hex bytes into RCON	The expert CLI cannot express this operation in this version	Explain the limitation clearly; do not invent parameters. Offer the GUI/RPC path instead.

Guardrails

Scope

• Only write hexadecimal bytes into the RCON/EEPROM region using the RCON algorithm (typically RCON.bin) via the cli_build_<op> + cli_execute actions (CLI) or the documented GUI/RPC fullConfigUploadHexToRcon flow followed by flash.clickUploadFileToDevice.
• Do not program files, read, erase, or run SRAM images from this skill. Recovery: hand off to the correct sibling skill.

Destructive actions (confirmation contract)

• RCON writes are destructive and can alter boot behavior; an incorrect value can render the board unbootable from any source. Always preview first: print target, algorithm, interface, port, start address, hex string, and byte count.
• Before the actual write step, summarize the intended operation and warn that a wrong RCON value may prevent the board from booting.
• Require an explicit user confirmation phrase (e.g. "yes, write RCON") before invoking the write action. This applies to both CLI and GUI/RPC flows. Recovery: if the user hesitates, stop; do not write.
• Never interpret RCON byte semantics on behalf of the user unless documentation or explicit user intent supports it.
• Never mix GUI and CLI in the same write invocation. Recovery: pick one mode up front.

Refuse-and-escalate

• Missing/ambiguous target, RCON algorithm path, interface, port, start address, or hex string: stop and ask.
• Never guess EEPROM/RCON size. Recovery: consult the installed documentation for the platform, and if unclear, ask the user.
• Board not in serial boot mode, or a previous session used a different target/algorithm: ask the user to reset the board into serial boot before retrying.
• RPC GUI: if hello fails, do not launch a second GUI blindly; follow the launch procedure in s32flashtool-rpc-api. Never use communicationDevice = UART; use COM with values like COM15,ftdi in comPort.

Output contract

• Report the tool's exit status and the exact address+bytes written as the tool acknowledged them. Do not claim success without a positive response from the tool.

Out of scope

• File-based flash programming. Use s32flashtool-upload-file-to-flash.
• Reading RCON/EEPROM. Use s32flashtool-read-rcon.
• Interpreting RCON byte semantics without documentation or explicit user intent.
• Guessing EEPROM/RCON size for the platform. Consult installed docs or ask.
• also see ## When not to use

Examples

• intentionally push examples into references/*.md