S32FlashTool Read RCON/EEPROM

Read the RCON/EEPROM region from a supported NXP S32 target.

This skill supports two execution modes:

• CLI mode using:
  • cli_build_fread + cli_execute
  • or the cli_build_<op> + cli_execute actions as fallback / preview path
• GUI mode using S32FlashTool GUI over RPC:
  • the matching gui_* action

This skill is operation-focused:

• it explains what the RCON/EEPROM read operation needs
• how to choose GUI vs CLI
• how to execute the read in each mode
• how to validate the outcome

When to use this skill

Use this skill when the user wants to:

• read RCON contents
• read EEPROM contents used as RCON configuration
• inspect boot configuration bytes stored in RCON/EEPROM
• dump RCON/EEPROM contents to console
• save the RCON/EEPROM region to a file

Do not use this skill when

Do not use this skill when:

• the user wants general flash reading
  -> use s32flashtool-read-flash
• the user wants to program/write/upload RCON/EEPROM data
  -> use the corresponding write/program workflow
• the user wants to erase flash
  -> use skill s32flashtool-erase-flash
• the user only wants to identify the processor
  -> skill 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.
• For GUI automation rules, also apply s32flashtool-rpc-api/SKILL.md.

Quickstart

1. Select mode see ## Mode selection policy
2. Gather inputs see ## Required inputs (use discovery calls from ## Preconditions)
   • RCON-specific: algorithm is RCON.bin; keep addr = 0x0 and size <= 24 unless documentation proves otherwise (see ## Address and size constraints)
3. Execute references/CLI.md or references/GUI.md
4. Validate see ## Validation

Operation mapping

User intent: read / dump / inspect / download RCON or EEPROM contents

GUI / RPC mapping

• Config key: fullConfigDownloadFromDevice
• Final action: flash.clickDownloadFromDevice
• Alternate config for save-to-file: fullConfigDownloadFromDeviceToFile
• Alternate final action: flash.clickDownloadFromDeviceToFile
• Destination: EEPROM (RCON)
• Requires initialization: yes

CLI mapping

• Preferred tool: cli_build_fread + cli_execute
• Expert fallback: cli_build_fread + cli_execute
• Required algorithm type: RCON.bin

Safety

• Destructive: no
• Confirmation required: no

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:
   • prefer the dedicated MCP tool cli_build_fread + cli_execute
   • do not silently switch to GUI unless the user requested GUI behavior
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 reading 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 built-in RCON algorithm, typically RCON.bin in the flash folder.
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 the correct boot mode for S32FlashTool communication.
8. For serial/UART workflows, the board is typically placed in serial boot mode.
9. If a different target/algorithm was used previously, a board reset / restart into serial boot may be necessary.

Recommended preparation

• Search in the installation examples folder for board-specific setup documentation.
• Search indexed documentation for board-specific RCON usage and boot configuration notes.
• If needed, read MCUID first to help confirm the processor family.
• If the port is not known, discover it before reading.

Required inputs

Collect or confirm the following:

• s32flashtool_folder
• target
• algorithm (normally RCON.bin)
• interface
• port
• addr
• size

Address and size constraints

• RCON/EEPROM size is typically 24 bytes total.
• addr should normally start at 0x0.
• size should normally be between 1 and 24 bytes.
• Do not request a size greater than 24 unless reliable documentation for the specific target proves otherwise.

Optional inputs

• file_path for save-to-file workflows
• binary_output / binaryMode
• extra_args only if explicitly needed

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 when a file path is provided.
• addr and size may be decimal or hexadecimal.
• Prefer addr = 0 when the user wants the full RCON/EEPROM region.
• Keep size <= 24 unless the target documentation proves otherwise.
• 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

After a successful read, validation may include:

• confirming that the read completed successfully
• checking that the output size matches the requested size
• checking that the file was created when reading to a file
• inspecting the returned bytes
• comparing the result against expected RCON structure or known boot settings

Practical validation examples

• confirm the dump file exists
• inspect all 24 bytes
• compare the bytes against expected boot configuration
• rerun a small read if the user wants confirmation

Failure modes

Recognize these RCON-read-specific failure modes from tool output and respond appropriately. They are distinct from generic path/port/boot-mode errors covered in "Error handling" below.

Target / algorithm mismatch

• Symptom: tool output indicates the algorithm does not match the device, RCON is not accessible, or the read returns implausible content (all 0xFF or all 0x00, or a value that does not match any documented RCON layout for the board).
• Interpretation: the supplied target and/or algorithm is wrong for the connected board, or the RCON path is not initialized for this device family.
• Response:
  • Stop. Do not retry with a different algorithm by guessing.
  • Re-run discovery: list_platform_files action (bin_type="supported") and consult the matching supported_<platform>_devices.txt.
  • If the processor family itself is uncertain, apply skill s32flashtool-read-mcuid first.

File-write failure when saving to disk (CLI or GUI)

• Symptom: the tool reports success in reading RCON bytes but the output file does not exist or is empty.
• Interpretation: the parent folder of file_path does not exist or is not writable. The device read likely succeeded; the file-write step failed independently.
• Response:
  • Do not report the read as failed on the device side.
  • Confirm the parent folder exists and is writable.
  • Ask the user for a different output path.

Error handling

If the operation fails:

1. Report the exact failure clearly.
2. Check:
   • target path
   • algorithm path
   • interface
   • port
   • address
   • size
   • boot mode
3. If using UART, remind the user to confirm the board is in serial boot mode.
4. If a different flash algorithm was used before, suggest restarting the board in serial boot mode.
5. If GUI mode was requested and RPC is unavailable:
   • explain that GUI/RPC is not reachable
   • ask whether CLI fallback is acceptable

Do not

• Do not use this skill for general flash reading.
• Do not guess target/device compatibility.
• Do not guess COM ports.
• Do not silently switch between GUI and CLI.
• Do not use raw shell commands instead of MCP tools.
• Do not use communicationDevice = UART in RPC GUI workflows.
• Do not invent RPC actions or model keys.
• Do not read beyond the supported RCON/EEPROM size unless verified by documentation.

Quick decision summary

• User asked for GUI / S32FlashTool window / RPC
  -> use GUI/RPC flow

• User asked for CLI / command line / shell
  -> use CLI flow

• User did not specify
  -> prefer cli_build_fread + cli_execute

• User wants the full RCON region
  -> use addr = 0x0, size = 0x18

• Board/boot uncertainty
  -> pause and clarify serial boot / hardware setup

Guardrails

Scope

• Only read the RCON/EEPROM region using the RCON algorithm (typically flash/RCON.bin) via CLI (cli_build_fread + cli_execute or execute_expert) or the documented GUI/RPC flow.
• Do not use for general flash reading (use s32flashtool-read-flash).

Destructive actions

• Read-only. If the user asks to write RCON afterward, hand off to s32flashtool-write-rcon and confirm there.

Refuse-and-escalate

• Missing target, RCON algorithm path, interface, port, or size: stop and ask.
• Do not read beyond the supported RCON/EEPROM size for the device. Recovery: cap at the documented size and warn the user if the requested range exceeded it.
• RPC GUI: use communicationDevice = COM, never UART.

Output contract

• Return the raw RCON bytes as reported by the tool, plus the address and size read. Do not interpret RCON semantics unless documentation or explicit user intent supports it.

Out of scope

• General flash reading. Use s32flashtool-read-flash.
• Programming or writing RCON/EEPROM data. Use s32flashtool-write-rcon.
• Erasing flash. Use s32flashtool-erase-flash.
• Identifying the processor. Use s32flashtool-read-mcuid.
• Reading beyond the documented RCON/EEPROM size for the device.
• Interpreting RCON byte semantics without documentation or explicit user intent.

Examples

• intentionally push examples into references/*.md