RNS510 Serial Console Commands

RNS510 Serial Console: Command Reference

A consolidated reference of every real command confirmed to be understood by the RNS510 head unit's own APPS processor, over its real, physical serial debug console — the same real VxWorks tShell documented on Theft Protection and the CAN Gateway (wiring diagram, 115200 baud, TpPvVerifyPin confirmed live). This page is a scannable reference; the full disassembly evidence and narrative for each command lives on the pages linked from each section below — this page doesn't repeat that evidence, only indexes it.

Why these are real shell commands, not just script syntax: every WA/*.WSH file flashed onto the unit is run via DLSCRIPT.TXT's own RUN_SHELL_SCRIPT command (see SWL Disc: Boot Chain and Build System) — i.e. these .WSH files are fed line-by-line into the exact same real VxWorks target shell reachable interactively over the serial console. Everything below is confirmed either by direct disassembly (the SetCoding/pReg family, CTEST.OUT) or by real, literal usage in an actual .WSH script flashed on a real disc (the shell built-ins) or by a real community tool's own confirmed live usage (TpPvVerifyPin, version).

Vehicle coding / register-data functions

Implemented in WA/CTEST.OUT, a real, complete, standalone PowerPC ELF object loaded into the shell via ld < /tffs0/lib/diag/ CodingTest.out before these become callable. Its real .symtab lists 102 entries; 27 of them are GLOBAL FUNC symbols — i.e. 27 real, shell-callable functions, not the 7 this project had individually examined before. Dumped directly from the ELF (struct.unpack against .symtab/.strtab, no tooling beyond Python's own struct), grouped by the real source file each belongs to (CodingTest.c/ RegTest.c/ConfigFblockTest.c, per the object's own STT_FILE symbols). All 27 are now fully disassembled — see HOST BSP and Vehicle Coding for the detailed evidence on the original 9; the rest are documented directly in the tables below.

CodingTest.c (the SetCoding/TestCoding family):

Command	Size	Status	What it does
SetCoding	620B	🟢	SetCoding(reg, value, offset, width) — patches the UDS "long coding" byte array via ReadEcuData/WriteEcuData (register 0x400 → real ECU id 0x3400)
TestCoding	472B	🟢	Reads back and checks the coding byte array (the function this project's own first capstone test targeted)
SetCodingHex	900B	🟢	SetCodingHex(reg, hex_string, offset, width) — manually parses an ASCII hex-digit string ('0'-'9'/'A'-'F'/'a'-'f') a byte at a time into a local binary buffer, then reads the main coding-data array via CodingApi_GetCodingData(reg, buffer, 0xff), clamps offset/width against the real returned array length (a genuine bounds check — truncates the copy instead of overflowing), memcpys the parsed bytes in at offset, and writes the patched array back via CodingApi_SetCodingData(reg, buffer, length)
SetDetail	280B	🟢	SetDetail(reg, value_ptr, width, offset) — reads a SEPARATE real "coding detail" byte array via CodingApi_GetCodingDetail(reg, buffer, offset), memcpys width bytes into it at the given position, writes it back via CodingApi_SetCodingDetail(reg, buffer, length). Structurally identical to SetCoding, but through the CodingApi_* family instead of ReadEcuData/WriteEcuData
TestDetail	692B	🟢	TestDetail(reg, offset) — reads the same detail array via CodingApi_GetCodingDetail(), registers a change-notification callback (test_notify1) via CodingApi_RegisterNotificationDetail(reg, test_notify1), then dumps the buffer as a real hex-dump, 16 bytes per printf row, advancing until the returned length is covered — a genuine diagnostic/read-and-display tool, not just a check
SetBrifHex	716B	🟢	SetBrifHex(reg, hex_string) — parses an ASCII hex string the same way as SetCodingHex, but skips the CodingApi_* layer entirely: calls WriteEcuData(0x63, 1, reg, buffer, length, 0) directly — a raw, lower-level UDS write-by-identifier, bypassing the coding/detail/data array abstractions above it. "Brif" still not expanded/confirmed as an acronym
SyncSave	216B	🟢	SyncSave(reg) — lazily registers a listener (global pFunc, slot sServiceReg+0x18) via svcb_addServiceListener() the first time it's called, then calls through pFunc with (&reg_byte, 1, 0, 0, 0) — same generic service-listener pattern as ResetEcu, through a different slot of the shared sServiceReg table
TestDoSync	92B	🟢	A trivial printf-only stub — the real notification callback registered by TestRegSync, confirming CodingApi_RegisterNotification's callback signature
TestRegSync	100B	🟢	TestRegSync(reg) — calls CodingApi_RegisterNotification(reg, TestDoSync) directly (reloc-confirmed). This resolves the 6th and final previously-unknown CodingApi_* function — see the note below the table
TestSDCRegister	280B	🟢	No arguments; the first function in the object (.text+0x0). Builds a real boot-manager shutdown-consumer lifecycle object (TestSDC: function-pointer slots for shutdown/rundown/runup/startup at +0/+4/+8/+0xc, a handle at +0x10, a name string at +0x14, a flag at +0x18) and registers it via bootMgrAddShutdownConsumer(&TestSDC). Names 4 more real but file-local functions: TestSDCStartUp/TestSDCRunDown/TestSDCRunUp/TestSDCShutDown
test_notify / test_notify1	88B each	🟢	Both trivial printf-only stub callbacks — generic diagnostic notification handlers (test_notify1 is the one TestDetail registers via CodingApi_RegisterNotificationDetail)
ResetEcu	324B	🟢	Disassembled. Takes 1 argument; only 0x63 (99) and 0xa0 (160) are valid — any other value just printfs a message and returns. For a valid value, resolves a function pointer from a real local vtable (pFunc[], indexed 0 or 1), lazily registering it via svcb_addServiceListener(&sServiceReg[idx*12]) the first time, then calls through it with a real argument tuple (struct_ptr, 1, 0, 0, 0). Which real ECU action 0x63 vs. 0xa0 triggers is not named in this object — only that these are the 2 real, valid reset modes

RegTest.c (the SetRegData/pReg family — see HOST BSP and Vehicle Coding for the full pReg vtable layout):

Command	Size	Status	What it does
SetRegData	872B	🟢	SetRegData(reg, value, ?, width, extra) — same shape as SetCoding via the pReg vtable
SetRegDataHex	1152B	🟢	Same, value as a hex string
SetRegDataStr	668B	🟢	Variable-length write: strlen()s and memcpys the string directly, bounds-checked against 0xfe
ReadRegData	448B	🟢	Pure read half, no write-back
DeleteRegData	252B	🟢	Requires pReg's accKey already non-zero
SaveRegData	280B	🟢	9-arg real signature; no .WSH script examined calls it
RegTestDoSync	108B	🟢	A trivial printf-only stub — the registry family's own notification callback, parallel to CodingTest.c's TestDoSync
TestRegistrySync	248B	🟢	TestRegistrySync(reg) — lazily registers a listener on &sServiceReg (global pReg) the first time it's called; then, if a cached access key (global accKey) is still zero, calls a function pointer at pReg+0x10 with (0) to acquire one and caches it; finally calls a function pointer at pReg+8 with (reg, RegTestDoSync, accKey) to register the notification. This is the RegTest.c family's own parallel to CodingTest.c's CodingApi_RegisterNotification — same purpose, different (generic, key-gated sServiceReg vtable) mechanism instead of a named CodingApi_* function

ConfigFblockTest.c — a real, separate MOST-bus config/ authentication protocol, now fully disassembled end to end (all 6 real functions) — ties directly to GATEWAY.FLI's own CodingShadow_*/CONFIG_FKTID_* protocol on Theft Protection and the CAN Gateway.

Command	Size	What it does
ConfigTestShadowInit	140B	No arguments. Registers configTestShadowSink as a real MOST receive callback via cc_tla_most_addSink() — the one-time setup step, called before anything else in this family
configLogin	244B	configLogin(str) — sends a real MOST message, sub-command 0x0a02, carrying the string's pointer/length and a callback pointer to configTestShadowSink
configRegister	312B	configRegister(a, b, c) — packs its 3 arguments into a 7-byte structure, sends sub-command 0x0a01 with that structure as payload
configTestReadReg	356B	configTestReadReg(a, b) — packs its 2 arguments into a 10-byte structure, sends sub-command 0x0a00
configSetRegHex	1072B	configSetRegHex(id, hex_string, param3, param4) — builds the same 16-byte wire header as the state machine below (id and param4 as 32-bit fields, param3 as a 16-bit field, a reserved byte, then message-type byte 3, then a 4-byte payload-length field), parses hex_string into raw bytes appended after that header, and sends it via cc_tla_most_send() with sub-command 0x0a00 — the same sub-command value configTestReadReg uses, but here carrying an arbitrary hex-encoded payload instead of a fixed 10-byte struct. This is the generic/raw send path underlying the fixed-shape helpers above it
configTestShadowSink	1264B	The real receive callback — see the state machine below

A real, complete, confirmed protocol state machine — all from disassembling configTestShadowSink itself, the function every message above names as its own reply callback:

• Every incoming message's byte 0 is a real type tag. Type 3 = a direct reply to a previously sent command — the real sub-command value is re-read from the SAME 0x0a00/0x0a01/0x0a02 field (offset 0x16) to decide which of 3 logging paths to take (a result byte at offset 0x18, a length at offset 4); any other sub-command value falls into a 4th, generic/unknown path. Type 2 = a real FBlock-availability notification, carrying one of 2 literal 32-bit magic values at offset 0x10:
  • 0x20000000 — the remote config FBlock is NOT available; clears the real global m_fConfigAvail.
  • 0x40000000 — the remote config FBlock IS available. This path does real, concrete work: calls cc_tla_most_getLocalDeviceId() and stores the result into the real global m_wHostDeviceId (confirming exactly where/when that value — embedded in every outgoing message above — actually gets set), sets m_fConfigAvail = 1, then immediately sends ANOTHER real message back out: type 3, length 5, sub-command 0x0001 — a 4th real sub-command value, distinct from the 0x0a0x group, sent automatically the moment the remote FBlock appears (plausibly a real "get info"/capabilities query — 0x01 is also GET_ALL's own real opcode in the generic BAP catalog documented on HOST BSP and Vehicle Coding, though this specific ConfigFblock protocol otherwise uses its own private 0x0a0x numbering, so this connection is suggestive, not confirmed).
  • Any other type 0 byte value falls through to a final generic logging path.

Net real sequence this confirms: ConfigTestShadowInit() first registers the receive sink → the remote config FBlock eventually announces itself available (type 2, 0x40000000) → the local device ID is fetched and cached, m_fConfigAvail is set, and a 0x0001 query is sent automatically → only then would configLogin/ configRegister/configTestReadReg (whichever an as-yet-undisassembled caller chooses) send their own real 0x0a0x requests and get a type-3 reply back through the same sink.

The send side's own real wire format, confirmed by disassembling configSetRegHex (it builds the message by hand instead of through a fixed-shape helper like configLogin/configRegister): the MOST message descriptor passed to cc_tla_most_send() carries, at the offsets used throughout this family, a type byte (3), a total frame-length halfword, a pointer to the payload buffer, the configTestShadowSink callback pointer (installed again on every send, not just once at init), a destination-device halfword (m_wHostDeviceId, read back out of the very global configTestShadowSink fills in), a fixed byte pair 0xf0 0x50 (plausibly a real MOST FBlockID/InstID pair for this ConfigFBlock), and the sub-command halfword at offset 0x16 — directly observed here being set to 0x0a00, matching the value inferred from the receive side. The payload buffer itself is just as simple: two 32-bit fields, a 16-bit field, a reserved byte, the same message-type byte (3) again, a 4-byte payload-length field, then the raw payload bytes. This confirms the receive-side field layout inferred above from the send side as well, end to end.

A real, previously-undocumented external function family this object depends on (not defined here — shndx=0/UNDEF, meaning they must already exist in the live VxWorks image for CTEST.OUT to link against). All 6 now resolved: via SetDetail/TestDetail, CodingApi_GetCodingDetail(reg, buffer, offset) (read), CodingApi_SetCodingDetail(reg, buffer, length) (write), CodingApi_RegisterNotificationDetail(reg, callback) (register a change-notification callback) — a real, separate "coding detail" array, parallel to but distinct from the UDS long-coding array SetCoding operates on; and via SetCodingHex (above), CodingApi_GetCodingData(reg, buffer, maxlen) (read) and CodingApi_SetCodingData(reg, buffer, length) (write) — the main coding-data array, a third sibling array alongside the UDS long-coding array and the "detail" array; and via TestRegSync, CodingApi_RegisterNotification(reg, callback) (reloc-confirmed) — the main array's own change-notification registration, parallel to CodingApi_RegisterNotificationDetail. All 6 CodingApi_* functions are now resolved. Also real and already expected: ReadEcuData/WriteEcuData, cc_tla_most_addSink/cc_tla_most_send/cc_tla_most_getLocalDeviceId, the bootMgrNotify*/bootMgrAddShutdownConsumer lifecycle family, svcb_addServiceListener, plus real logging infra (LOG_PRINT, ErrorLog_SetError, _DebugList) not previously named individually.

Status legend: 🟢 fully disassembled, real confirmed behavior; ⚪ real and confirmed present (name, real size, real source file) but not yet disassembled.

Real, confirmed register/coding-array values (not an exhaustive list — see HOST BSP and Vehicle Coding and SWL Disc: Boot Chain and Build System for the full evidence and every real example line found):

Target	Meaning	Real values seen
SetCoding(0x400, value, 1, 1)	Manufacturer	0x02=VW, 0x05=Skoda
SetCoding(0x400, value, 2, 1)	HDD active	0/1
SetCoding(0x400, value, 5, 1)	Tuner "RUDI" active	real internal tuner codename
SetCoding(0x400, value, 6, 1)	DAB active	0/1
SetCoding(0x400, value, 7, 1)	SDARS (Sirius) active	0=not active (EU), 1=plain active, 2=real enum value seen on NAR discs (plausibly XM=1/Sirius=2)
SetCoding(0x400, value, 8, 1)	MPEG active	0/1
SetCoding(0x400, 0, 9-15, 1)	Reserved/unused option bits	every real factory script found sets all 7 of these to 0 — real, confirmed-present coding bits with no observed real use yet
SetRegData(0xa91, 0, 0, 2, 0x8a)	"Delete Presets"	—
SetRegDataHex(0x21, "01"/"00", 0x0, 0x1, 0x1)	Testmode active/inactive	real toggle — see the "unlock pattern" section below
SetRegDataHex(0x60, "01"/"00", 0x0, 0x1, 0x1)	"NoSpeech" (voice recognition disabled)	01=disabled, 00=enabled — the real toggle behind the RECOG_OF/RECOG_ON factory scripts
SetRegDataHex(0x0B3A, "012C", 0x0, 0x2, 0x89)	Speed limit DVD/TV override	0x012C = 300 km/h, overrides the real factory "no video while driving" lockout
SetRegDataHex(0x0a0a, "01", 0x0, 0x1, 0x1)	"Big VW Splashscreen in NAND: Not Active"	Skoda-specific real per-brand splash-screen selector

Screenshot capture (SCREENSH.OUT)

A real, separate, standalone PowerPC ELF object (WA/SCREENSH.OUT, 14754 bytes, byte-identical across every firmware version it appears in) — loaded the same way as CTEST.OUT (ld < /tffs0/...) and confirmed real/shell-callable by a real flashed WA/SCREENSH.WSH, whose entire content is the literal line sp DoScreenshotHMI (sp = the real shell built-in that spawns a task by function name — see below). This is a genuinely previously-undocumented RNS510 diagnostic capability: live BMP screenshots of the unit's own display, grabbed straight off a real unit over the serial console.

Confirmed two ways at once: disassembly of all 6 of its real FUNC symbols, AND — unusually — the object embeds its own complete, real help text (DoScreenshotUsage's literal printf strings), so this table is effectively quoting the vendor's own documentation directly:

Command	Real signature	What it does
DoScreenshot	DoScreenshot([szFilename],[nOverlay])	Captures ANY single raw hardware overlay by number, no compositing. Real confirmed overlay IDs: 0=HMI, 1=Video, 2=Map (the embedded help text literally says "%i = HMI, %i = Map display, ...")
DoScreenshotHMI	DoScreenshotHMI([szFilename])	Shortcut for DoScreenshot(name, 0) — the HMI overlay alone
DoScreenshotVideo	DoScreenshotVideo([szFilename])	Shortcut for DoScreenshot(name, 1) — the video overlay alone
DoScreenshotMap	DoScreenshotMap([szFilename])	Shortcut for DoScreenshot(name, 2) — the map overlay alone
DoScreenshotGUI	DoScreenshotGUI([szFilename])	Not a single-layer dump — queries overlay 2 (map) AND overlay 0 (HMI) together and blends them, matching the embedded help text verbatim: "a blend screenshot of the HMI and map overlay" / "includes HMI and map display"
DoScreenshotUsage	DoScreenshotUsage()	Prints the full real help text this table is built from

Real, confirmed mechanics (from disassembling doScreenshot/ doScreenshotGUI/makeFilename/writeSwapWord/writeSwapDword): captures via uglsvdoOverlayQuery() + uglPageVisibleGet() (real VxWorks UGL graphics-library driver calls) to get the live framebuffer pointer, width, height and row stride for the requested overlay; each pixel is read as a native 16-bit value, byte-swapped, then expanded from 16-bit (RGB565-shaped: 5/6/5 bit fields) into a 24-bit RGB triple written through writeSwapWord/writeSwapDword (both confirmed little-endian byte-swap-then-fwrite helpers — real, deliberate endian conversion, since the CPU itself is big-endian PowerPC). The output is a real, standard, uncompressed Windows BMP file: magic "BM", a 54-byte header (0x36 pixel-data offset, 0x28-byte BITMAPINFOHEADER), 24 bits/pixel, BI_RGB (no compression), and a negative height (the standard BMP convention for top-down row order) — each row correctly padded to a 4-byte boundary. If no filename is given, a real default path/name is generated from the current time: literally /tffs0/[OverlayName]@D|M|YYYY|H:M:S.bmp (OverlayName is one of the real internal names HMIOverlay/ VideoOverlay/MapDisplay/MapDisplayAndGUI/Overlay, per command) — confirming output lands on the unit's own internal flash filesystem, /tffs0/, from where it would need a separate real transfer mechanism (FTP, the diag link, etc.) to retrieve. The embedded help text has one real, verbatim vendor typo: DoScreenshotGUI's example line says "/tffs0/screenshot.tga" even though the actual written format — confirmed by the "BM" magic byte and every other help line — is BMP, not TGA.

Real confirmed error paths (doScreenshot's own early-exit checks, each with its own distinct real printed message): invalid overlay id, overlay-information query failure, no visible page for the overlay, invalid DDB (device descriptor block), invalid video-memory address, and file-open failure.

Theft protection / PIN verification

Full evidence, the wiring diagram, and the real ClusterID vehicle-pairing security design: Theft Protection and the CAN Gateway.

Command	Real signature	What it does
TpPvVerifyPin	TpPvVerifyPin(<pin>)	Verifies a 4-digit PIN (real confirmed keyspace: 0-1999) against a stored hash (HWInfoGetPinHash()/NFGetNandFlashId()); replies with a line containing the literal substring "Hash valid" or "Hash invalid"

Real, named, related functions confirmed to exist (via string evidence in FHDD6.FLI itself) but not confirmed as separately callable shell commands: HWInfoGetPinHash(), NFGetNandFlashId(), CopyClusterIDFromNANDToNOR(), TpPvJapNavPresent(), TpPvGetUniqueIdentifier().

Real VxWorks shell built-ins

Standard WindShell syntax, confirmed by literal, real usage inside flashed .WSH scripts (not this project's own invention) — cross- checked against the BSP's own real shell help text ("sp adr,args... Spawn a task"), see HOST BSP and Vehicle Coding.

Command	Real example (from an actual flashed script)	What it does
ld <	ld < /tffs0/lib/diag/CodingTest.out	Load an object/library file, making its exported functions callable
sp	sp xdelete, "/tffs0/FLASH" / sp xcopy("/sda/mapsdvd","/hdb2/dvd")	Spawn a task calling the named function with the given arguments
rmdir	rmdir("/tffs0/FLASH")	Remove a directory
mkdir	mkdir("dvd")	Create a directory
cd	cd("/hdb2/dvd")	Change the shell's current directory
copy	copy("/sda/maps/hddfiles.log", "/hdb2/hddfiles.log")	Copy a file
IL_Flush	IL_Flush	Flush the InfoLog (ties to the BSP's own real InfoLog 1/2 flash regions)
dlpSetCyclicFlag	dlpSetCyclicFlag 1 / dlpSetCyclicFlag 0	Set/clear a real dirty-flash/power-loss-recovery flag, bracketing a risky flash step (CYCFLAG1.TXT/CYCFLAG0.TXT)
xcopy	xcopy "/cddos/CHARTS/ChannelArtsCache/128x88", "/hdb3/data/ChannelArtsCache/128x88"	Recursive directory copy — real source mount /cddos/ confirmed here for the first time (the SWL disc itself, mounted as a DOS filesystem during flashing)
xdelete	sp xdelete, "/hdb3/edb/sirius/NA_SIRIUS.DB3"	Delete a file or directory tree (used both bare and via sp)
hdTermFormat	hdTermFormat("/hdb1", 3) / hdTermFormat("/hdb2", 2)	Formats a real hard-disk partition with a given real filesystem-type number (2/3 seen; not independently decoded)
hdTermConfigurePartition	hdTermConfigurePartition(2, 2, 67, 33, 0, 0)	Real HDD partition-table configuration — confirmed present (commented out in every script seen; a genuinely risky, rarely-exercised real command)
API_DeleteSector	API_DeleteSector(0x0C)	Deletes a real low-level flash/NAND sector by ID — register 0x0C seen
INFOAPI_DeleteId	INFOAPI_DeleteId(0x60)	Deletes one real InfoLog record by ID. Real IDs confirmed via genuine vendor script comments: 0x60=HDD-coding info, 0x61=ECU 0xA0 data ("exists only virtually"), 0x62=errorlog, 0x65=BMW-only data
INFOAPI_DeleteWTILObjectsCurrentInfo	INFOAPI_DeleteWTILObjectsCurrentInfo()	Clears the current-info record for the real "WTIL" subsystem (see /hdb1/goldwtil.ssw/lastwtil.ssw below)
logStoreContext / logOutContext	logStoreContext(1) / logOutContext(1, 0)	Real logging-context save/output pair, run at the end of every real factory coding script seen, just before IL_Flush
SysCfgMainWriteRecoveryFlag	SysCfgMainWriteRecoveryFlag(0)	Writes a real system-config recovery flag — seen clearing it (0) as the first step of a real WTIL recovery procedure

Real, confirmed VxWorks mount points, used as arguments to the above: /tffs0/ (the unit's own local flash filesystem — True FFS, sysTffs.c), /hdb1/, /hdb2/, /hdb3/ (3 real, separate partitions on the internal hard disk — /hdb2/ is the root of the whole on-unit map-data tree, not just speech/; /hdb1/ holds real WTIL state files (goldwtil.ssw/lastwtil.ssw); /hdb3/ holds real Sirius TravelLink data, /hdb3/edb/sirius/NA_SIRIUS.DB3, and a real "ChannelArtsCache" image cache at 3 real fixed resolutions — 128x88, 71x50, 89x62 — see Sirius TravelLink and North America Discs), /sda/ (the SD card, when one is inserted — confirmed via the maps-tool SD-card install script, SWL Disc: Boot Chain and Build System), /cddos/ (the SWL disc itself, mounted read-only as a DOS filesystem during flashing — confirmed by xcopy pulling ChannelArtsCache images directly off it).

Meta / diagnostic commands

Confirmed via a real community tool's own live usage over the serial console (rns_code_finders, Theft Protection and the CAN Gateway).

Command	What it does
version	Returns a real VxWorks target-shell identity banner — confirmed substrings "Made on ", "Kernel:", "VxWorks", "tShell" (exact full banner text not captured)
help	Real WindShell command-listing request (the tool sends this, but its own response content was not captured/logged)

One real, unresolved command: a community tool (rns_code_finders v20's own "Stop" button) sends the literal 3-character string "x68" to the console. Its real purpose was never decoded — recorded here rather than guessed at, so a future session with real hardware access can test it directly.

What this page does NOT cover

• DLSCRIPT.TXT's own command set (BOOTMODE_SWL, RUN_SHELL_SCRIPT, FILE_UPDATE, LOAD_ECU_BLOCK, etc.) — these are understood by the SWL.FLI bootstrap loader while flashing, not typed at an interactive shell. See SWL Disc: Boot Chain and Build System.
• BLSCRIPT.CFG's own command set (LOAD_FLASH_IMAGE, SET_BOOT_MODE, REBOOT) — understood by the hardware bootloader, one stage before SWL.FLI even runs. Same page as above.
• The CAN-gateway (GATEWAY.FLI/ST10F276E) chip's own real diagnostic override interface ("THP: Diag: Override CounterPINRetry" etc.) — a register-override mechanism reached through an as-yet-unlocated indirect dispatcher on a completely different chip, not a text command typed over this serial link. See Theft Protection and the CAN Gateway.
• The real BAP/MOST-bus function-ID catalogs (GET_ALL, DESTINATION_LIST, TUNE_UP, etc.) — a binary CAN-bus protocol, not a text shell command set. See HOST BSP and Vehicle Coding.