Differences

This shows you the differences between two versions of the page.

--- hardware:tbox [2026/08/12 12:04] – external edit 127.0.0.1
+++ hardware:tbox [2026/08/12 13:37] (current) – [Remote preconditioning is in the firmware] steini
@@ Line 173: / Line 173: @@
 ===== Remote preconditioning is in the firmware =====
-Although the printed manuals say the car has no remote climate, the capability **is present in the TBox firmware** — it was simply orchestrated by the OEM cloud, which is now gone.
 The telematics app contains the remote-control machinery: routines to **check preconditions**, **wake the MCU**, and drive **A/C, rear-defrost and door-lock** remote-control state. The one feature traced end to end is a **mid-trip battery pre-heat** (warm the pack before a fast-charge stop):
-  * **Trigger is cloud-only.** It fires on a command field delivered by the (dead) cloud; **no local trigger exists in the code**, which is why it no longer works.
+  * **Trigger is cloud-only.** It fires on a command field delivered by the (dead) cloud; **no local trigger exists in the code**.
-  * **Pre-checks before it acts:** HV system on, DC-DC idle, on-board charger idle, **SoC > 10 %**, **battery minimum temperature < 15 °C**, **range > 20 km** — classic "skip if already charging, already warm, or nearly empty" logic.
+  * **Pre-check:** HV system on, DC-DC idle, on-board charger idle, **SoC > 10 %**, **battery minimum temperature < 15 °C**, **range > 20 km** — classic "skip if already charging, already warm, or nearly empty" logic.
-  * **How the command reaches the car:** not an ordinary broadcast frame — the TBox sends a **security-gated UDS routine over the diagnostic CAN**, and the MCU relays those bytes to the bus. The only frame the TBox emits on its own is a network-management **wake frame**.
+  * **How the command reaches the car:** the TBox sends a **security-gated UDS routine over the diagnostic CAN**, and the MCU relays those bytes to the bus. The only frame the TBox emits on its own is a network-management **wake frame**.
-The MCU side confirms the mechanism: it defines a **remote CAN-message descriptor** carrying //which bus//, //data source//, a **"requires HV on"** flag and a **repeat-count + cycle-time** — i.e. the Linux side can ask the MCU to send a parameterised, repeated CAN message gated on vehicle power. Recognised **wake sources** include an **RTC timer**, the charge signal, CAN activity, the modem RING line, USB and ACC — so the TBox can **wake itself on a schedule** with the car parked.
+The MCU defines a **remote CAN-message descriptor** carrying //which bus//, //data source//, a **"requires HV on"** flag and a **repeat-count + cycle-time** — i.e. the Linux side can ask the MCU to send a parameterised, repeated CAN message gated on vehicle power. Recognised **wake sources** include an **RTC timer**, the charge signal, CAN activity, the modem RING line, USB and ACC — so the TBox can **wake itself on a schedule** with the car parked.
 **What that means for reviving preconditioning:** you cannot ride the original cloud (see below), so the practical path is **local** — with root on the TBox, invoke its own remote-control routine directly, or replay the UDS command from your own CAN node.
@@ Line 188: / Line 187: @@
 The TBox filesystem carries the vehicle's **CAN database (DBC)** — the message IDs, bit positions, scaling and value tables for the whole car (VCU, BMS, OBC, BCM, DCDC, ESP, MCU, TBOX…). It is the decoder ring behind the [[:cansignals|signal list]] and the practical key to reading or reproducing any vehicle signal, including pack voltage/SoC, TPMS, and the door/lock/defrost and A/C remote-control frames relevant to preconditioning.
+===== The TBox ↔ MCU interface (SCOM) =====
+The Linux side talks to the S32K144 MCU over an internal **SCOM** (serial-comms) request/response
+protocol (''scom_tl_proc_con_req/res'', ''data_req'', ''data_ok/ng_res''). On top of that transport it
+issues a set of get/set operations. What can be identified from the firmware:
+^ Operation ^ Dir ^ Parameter ^ Purpose ^
+| ''get_mcu_sw'' / read mcu version | get | — | S32K MCU firmware version |
+| ''get_mcu_upg_ver'' | get | — | MCU bootloader / upgrade version |
+| ''ReadBigVersion'' / ''Get_BigVersionInfo'' | get | — | multi-ECU "big version" block |
+| ''get_pow_voltage'' | get | — | 12 V supply voltage |
+| ''get_power_state'' | get | — | power / ignition state (ACC / IGN / sleep) |
+| ''get mcu rtc time'' | get | — | MCU real-time-clock |
+| ''get_gps_ant'' | get | — | GPS antenna status (open / short / OK) |
+| ''get_gps_module'' | get | — | GPS module status |
+| ''NMTBOX_WakeSource'' | get | — | what woke the TBox (RTC / charge / CAN / modem RING / USB / ACC) |
+| ''get mcu cfg'' | get | cfg id | read a persistent config item by id |
+| ''get_signal_from_name'' / ''get_signal_value'' | get | signal name | read **any** vehicle CAN signal from the on-board DBC (value + unit + ECU + last value) |
+| ''setrtc'' | set | time | set the MCU RTC |
+| ''set_power_state'' | set | state | set power state |
+| ''set_NM_wakeUp'' | set | wake spec | arm a network-management wake (schedule a future self-wake while parked) |
+| ''set_signal_flag'' | set | signal | flag a signal for sending |
+| ''cfg_set_by_id'' / ''scom_mcu_cfg_sync'' | set | cfg id + value | set / sync a persistent config item by id |
+| ''canMsg_remote'' | set | MsgID + 8 data bytes (+ bus, repeat-count, cycle-time, requires-HV flag) | send a parameterised CAN frame onto the vehicle bus — the remote-control / preconditioning path |
+| ''WriteBigVersion'' / ''Set_BigVersionInfo'' | set | version block | write the "big version" block — **security-gated** (UDS Security Access) |
+Persistent config items (''cfg_*'', get/set by id) seen so far: ''CFG_ITEM_ACOTA_VIN'' (VIN),
+''CFG_ITEM_ECALL_MODE_TYPE'', ''CFG_ITEM_ECALL_VEH_TYPE''.
+//These are the operations identifiable from firmware strings; the SCOM protocol's exact message IDs
+and full parameter encodings are not fully reverse-engineered, so treat this as a working map, not a
+complete spec. The ''get_signal_from_name'' side resolves against the on-board CAN database (BCM_*,
+BMS_*, ABM_*, AC_*, VCU_*, …), which holds the full signal list — far more than can be tabled here.//
 ===== The OEM cloud is dead =====