20260928-0836-key-wireless-service-and-mcu Add a wireless configuration and update path to Key and re-select its MCU
- status: completed
- createdAt: 2026-09-28 08:36
- approvedAt: 2026-09-28 09:00 (owner: "可以")
- relatedTask: 20260928-0836-key-wireless-service-and-mcu
Context
章节标题：“Context”What the documents say today
章节标题：“What the documents say today”P05-key.mdR0.2 §1: Key is the wired panel for fixed positions; four functional wires (V+, GND, CAN-H, CAN-L); control goes Key → YBO CAN → Core without Air Hub, Mate, internet or phone. §6: "本产品不增加 Air 的无线认证配对要求". §7: non-wireless compliance row (EMC, RoHS, WEEE, GPSR, CRA when networked). The brief says "不依赖无线与云".- KEY-05: Key does not sleep; it keeps receiving while the bus is idle; static current ≤5 mA at 12 V (60 mW input).
- X01 §4.7 already defines CFG and OTA over CAN between a hub and a node, with signed chunks. The frame sizes were written for 64-byte CAN FD frames and X01 §1 records that they must be recomputed for Classical CAN (8-byte payload, 500 kbit/s, decision of 2026-09-11).
- Design appendix R0.2: STM32G0B1CE + TJA1463 + LP5024 + LMR36506-Q1 / TLV755P.
- Core has no radio. Mate and Air Hub have Wi-Fi and BLE.
So configuration and update of a Key are possible today only through a Mate or Air Hub on the same bus. A boat with Core and Key only has no wireless entry point.
Static-current budget
章节标题：“Static-current budget”TJA1463 in Normal mode, recessive: ICC 7 mA typical at 5 V (datasheet). At 85 % buck efficiency that is about 41 mW of the 60 mW input budget, leaving roughly 3 mA at the logic rail for the MCU and everything else.
| MCU | Current while holding CAN reception | Total static at 12 V | Against ≤5 mA |
|---|---|---|---|
| STM32G0B1CE at 16 MHz | ~1.5 mA (93 µA/MHz) | ~4.2 mA | meets, small margin |
| TI CC2745R10-Q1, Idle mode | 1.45–2.1 mA at 3.3 V (SWRS304D) | ~4.2–4.5 mA | meets |
| ESP32-H2, modem-sleep 64 MHz | 5–10 mA (datasheet v1.3) | ~6–8 mA | exceeds |
| ESP32-C6, modem-sleep 80 MHz | 14–25 mA (datasheet v1.5) | ~10–16 mA | far exceeds |
| nRF54L15 + MCP2515 (SPI CAN controller) | MCU idle ~3 µA; MCP2515 operating ≤10 mA max at 5.5 V, 25 MHz | ~6–8 mA | exceeds 5 mA, fits a relaxed limit |
| nRF54L15 + MCP2518FD | MCU idle ~3 µA; MCP2518FD 15 mA typical at 40 MHz SYSCLK (lower clocks not listed) | ~11 mA at 40 MHz | exceeds |
ESP32 light-sleep is not usable: TWAI does not run in light-sleep and waking on the CAN RX pin loses the first frame, which contradicts KEY-05.
The logic rail is an LDO from 5 V, so every milliamp at 3.3 V costs a milliamp at 5 V; totals are
(I_5V × 5 V) / 0.85 / 12 V. With an external CAN controller the controller, not the MCU, sets
the static current, so the Air chip does not come out lower than the ESP32-H2.
Candidate architectures
章节标题：“Candidate architectures”| A. ESP32-H2 single chip | B. STM32G0B1CE + BLE module | C. BLE + CAN automotive MCU | D. No radio in Key | |
|---|---|---|---|---|
| Parts | ESP32-H2-MINI-1 module | existing MCU + pre-certified BLE module (TI CC2340R5MODA 7×10 mm, or an nRF54L module) on UART | TI CC2745R10-Q1 or NXP KW45, chip-down | unchanged |
| Static at 12 V | ~6–8 mA | ~4.2 mA (module in shutdown, 165 nA, until the service window) | ~4.2–4.5 mA | ~4.2 mA |
| CAN | TWAI, Classical only | FDCAN (headroom for CAN FD) | CAN FD | FDCAN |
| Firmware images | one | two (MCU and BLE), update of the MCU passes through the module | one | one |
| RF certification | modular (pre-certified module) | modular | full chip-down RF design and certification | none for Key |
| Security hardware | Secure Boot v2, flash encryption, eFuse | STM32: RDP and securable memory; module: depends on part | HSM / EdgeLock, secure boot | as today |
| Toolchain | ESP-IDF, shared with the Air Hub ESP32-C6 | STM32 + module vendor | a new vendor toolchain | as today |
| Wireless entry when there is no hub | yes | yes | yes | no: needs Mate, Air Hub or a separate BLE-to-CAN service dongle |
| GPIO for Key 8 | 19, about 16 used, no spare | ample | 23 (CC2745) | ample |
NXP KW45 figures (RX 4.7 mA, TX 4.6 mA at 0 dBm, <100 nA lowest mode, FlexCAN with CAN FD, AEC-Q100 Grade 2) are from the product page; its run and idle currents are behind a login and are not verified. ESP32-C6 brings Wi-Fi, a second TWAI and more GPIO, none of which Key needs, at two to three times the current of the H2; it is not proposed.
What wireless adds besides the chip
章节标题：“What wireless adds besides the chip”- Compliance. Key becomes radio equipment: RED including the cybersecurity requirements of Delegated Regulation (EU) 2022/30 (EN 18031 series, mandatory since 2025-08-01), FCC Part 15 and the other destination approvals, instead of the non-wireless row.
- Attack surface. Key is the fallback control path for critical circuits
(
P05-switch.md§3). A radio on that device must not be able to issue or alter a control command. - X01. If the BLE-equipped Key also relays CFG / OTA to other nodes, it takes the hub role of X01 §4.7 for those transfers; the Classical CAN chunking of §4.7 has to be settled first.
Option E, added 2026-09-28: the Air chip
章节标题：“Option E, added 2026-09-28: the Air chip”The owner asked why Key does not use the same chip as Air. nRF54L15 has no CAN controller, so it needs an SPI CAN controller next to the TJA1463: MCP2518FD (CAN FD, already a CAN source in the Air Hub combinations) or MCP2515 (Classical CAN). Zephyr has drivers for both.
| E. nRF54L15 + SPI CAN controller | A. ESP32-H2 | |
|---|---|---|
| Platform | same SoC, SDK (nRF Connect SDK / Zephyr), MCUboot and BLE security code as Air and Tag | ESP-IDF, shared only with the Air Hub uplink C6 |
| Pairing without a display | NFC-A tap gives authenticated OOB, the same method as Air (AIR-O-02) |
printed setup code with PAKE, or passkey on the keys |
| CAN | external controller; CAN FD possible with MCP2518FD | on-chip TWAI, Classical only |
| Parts | SoC + CAN controller + its crystal + transceiver | SoC + transceiver |
| GPIO | 31 (QFN48) | 19 |
| Memory | 1.5 MB / 256 KB (L10: 1 MB / 192 KB) | 4 MB flash in module / 320 KB |
| Static at 12 V | ~6–8 mA with MCP2515; ~11 mA with MCP2518FD at 40 MHz | ~6–8 mA |
| RF certification | pre-certified nRF54L15 modules exist | pre-certified module |
| Service tool | one phone tool and one GATT service for Air and Key | separate implementation |
Owner input of 2026-09-28: power is not a constraint; wired-bus flexibility and price are
章节标题：“Owner input of 2026-09-28: power is not a constraint; wired-bus flexibility and price are”The owner stated that Key is permanently powered and is not a low-power product, and asked which option makes a later RS-485 or CAN port easier and what the parts cost.
Wired-bus flexibility:
| ESP32-C6 | ESP32-H2 | nRF54L15 | |
|---|---|---|---|
| CAN | 2× TWAI on chip; each port needs only a transceiver | 1× TWAI on chip | none; each port needs an SPI CAN controller, its crystal and a transceiver |
| RS-485 | UART + transceiver; 2 UART + 1 LP UART | UART + transceiver; 2 UART | UART + transceiver; 5 serial instances shared with SPI and I2C |
| GPIO | 30 (QFN40), 22 (QFN32) | 19 | 31 (QFN48) |
| Key 8 with CAN + RS-485 + I2C + USB | fits with spare | about 17 of 19, strapping pins included | about 20 of 31 (SPI CAN takes five) |
| CAN FD | no (TWAI is Classical) | no | yes with MCP2518FD |
LCSC retail prices, 2026-09-28, USD at the 1k tier unless noted; retail, not a production quote:
| Part | Price | Note |
|---|---|---|
| ESP32-H2FH4 (chip, 4 MB flash) | 1.69 | C22470214; the H2-MINI-1 module is not listed |
| ESP32-C6-MINI-1-N4 (module, antenna, pre-certified) | 2.83 at 1.3k | C5736265; stock 0 on the day; the C6 chip is not listed |
| nRF54L10-QFAA | 2.40 | C44800139; nRF54L15 is not listed and costs more |
| MCP2518FD (SOIC-14) | 0.95 | C626758 |
| MCP2515 (TSSOP-20) | 0.85 | C185941 |
| TJA1463 (SIC transceiver) | 0.66 | C3233821 |
| TJA1051T/3 (plain transceiver) | 0.41 at 2.5k | C38695; does not meet the X01 SIC requirement |
| SP3485 (RS-485) | 0.14 | C8963 |
| THVD1450 (RS-485, ±18 kV ESD class) | 0.57 | C2671361 |
| STM32G0B1CET6 / CET6N | 7.71 / 4.42 at 100 | C5270267 / C2978903; both stock 0 |
Radio + MCU + CAN controller, before transceiver, passives and antenna:
| Option | Parts | Sum |
|---|---|---|
| ESP32-C6 module | ESP32-C6-MINI-1-N4 | 2.83, antenna and modular certification included |
| A. ESP32-H2 chip-down | ESP32-H2FH4 | 1.69, plus crystal, matching, antenna and own RF certification |
| E. nRF54L10 / L15 chip-down | nRF54L10 + MCP2518FD | 3.35 (3.25 with MCP2515), plus two crystals, matching, antenna, NFC loop and own RF certification |
| B. STM32G0B1CE + BLE module | 4.42–7.71 + module | highest |
Proposal
章节标题：“Proposal”Recommended after the owner's input: ESP32-C6 as a pre-certified module (ESP32-C6-MINI-1), the wireless path restricted to service, and KEY-05 relaxed to a static current of ≤20 mA at 12 V. With power no longer a constraint the C6's higher current stops being a reason to reject it, and it is the option with the most wired-bus headroom (two CAN controllers, three UARTs, more GPIO) at the lowest certified cost. The ESP-IDF toolchain is already in the line through the Air Hub. Option E (the Air chip) remains the alternative when one firmware platform and NFC pairing across Air, Tag and Key matter more than part count and price; option A (ESP32-H2) when the lowest chip price matters and 19 GPIOs are enough.
Superseded recommendation of earlier the same day, kept for the record: option E, nRF54L15 with an SPI CAN controller, and KEY-05 relaxed to ≤10 mA at 12 V.
Reasons: Air, Tag and Key then share one SoC family, one SDK, one bootloader and one implementation of the authenticated BLE service, which is the part of the firmware that EN 18031 and SEC-01…05 make expensive to get right and to maintain; NFC gives Key the same authenticated pairing as Air without a display; 31 GPIOs leave room that the H2 does not. The cost is one more chip and its crystal, and a static current set by the CAN controller. The controller choice is an open item: MCP2515 meets ≤8 mA but is Classical-only; MCP2518FD keeps CAN FD headroom and matches the Air Hub part, but its current at a reduced clock must be measured or taken from the vendor before ≤10 mA can be claimed.
Requirements to add to P05-key.md (R0.3)
章节标题：“Requirements to add to P05-key.md (R0.3)”| ID | Requirement | Kind |
|---|---|---|
| KEY-18 | Wireless service interface (BLE) for configuration, diagnostics read-out and firmware update only; no load command, binding execution or CAN control frame may originate from it | must |
| KEY-19 | The radio is off in normal operation; a service window is opened by a defined physical action on the panel, lasts ≤10 min, closes on timeout, on completion and on power cycle, and is indicated on the LEDs | must |
| KEY-20 | Wired control (KEY-02, KEY-03, KEY-07) keeps its timing while the service window is open and during a firmware transfer; activation of new firmware happens only when no key is held | must |
| SEC-01 | Authorised, time-limited pairing with authentication; unauthenticated Just Works pairing is disabled in production (same wording as Air) | must |
| SEC-02 | Mutual authentication and encryption of the service link; per-device keys; no plaintext fallback | must |
| SEC-04 | A lost or replaced service tool can be revoked; factory reset needs the physical action | must |
| SEC-05 | unchanged, and now also covers images and configuration received over BLE: same signature and version checks as over CAN | must |
- §1: control remains independent of wireless; wireless is a service path. §2: static current ≤20 mA at 12 V with the reason (C6 modem-sleep 14–25 mA at the logic rail plus the transceiver). §5: add the wireless service interface to the ICD list. §6: rewrite for the service link. §7: move to the wireless compliance row. §8: open items KEY-O-09 (pairing method without a display: printed per-device setup code with PAKE, or passkey entry on the keys), KEY-O-10 (whether a Key may relay CFG / OTA to other nodes on the bus, and the X01 §4.7 chunking for Classical CAN), KEY-O-11 (SPI CAN controller: MCP2515 or MCP2518FD, clock and measured current).
Other pages
章节标题：“Other pages”- New evaluation
bizplan/product/switch/key/evaluations/wireless-service-mcu.md: the two tables above with sources, the budget arithmetic, the H2 versus C6 comparison. P05-key-design.mdR0.3: ESP32-C6-MINI-1 + TJA1463, block diagram, power budget, antenna keep-out behind an IP67 front panel, GPIO table with the second TWAI and a UART reserved for a later CAN or RS-485 port; nRF54L15 + SPI CAN, ESP32-H2 and STM32G0B1CE + module recorded as alternatives with the price table.P05-key-guide.mdR0.3: V-03 security tests for the service link, RF tests, service-window tests, OTA interruption over BLE.- Brief, package index,
P05-switch.md(compliance cell),compliance-matrix.md(Key leaves the non-wireless row),product-plan.md§P5,open-questions.md.
Verification: quality gate; grep that no page still says Key has no wireless without the "control path" qualifier; every existing KEY-nn, SEC-05, IF-01 and MFG-nn ID still present.
Risks
章节标题：“Risks”- A radio on the fallback control device is a security regression if KEY-18 is not enforced in firmware architecture (separate GATT service, no code path from the service task to the command builder) and tested under V-03.
- ESP32-H2 has 19 GPIOs; Key 8 uses about 16. Any added signal forces an I/O expander, which the 32-key configurations need anyway.
- ESP32 I/O is not 5 V tolerant; key lines and ESD paths must be designed for 3.3 V.
- An antenna behind a sealed IP67 panel on a metal console may have poor range; service use at arm's length tolerates this, but it must be measured.
- Compliance cost moves Key from the cheapest family row to the wireless row for every SKU.
- X01 §4.7 is not yet recomputed for Classical CAN; relaying to other nodes depends on it.
Scope
章节标题：“Scope”About ten files: Key spec, design, guide, brief, index, one new evaluation; line spec; compliance matrix; product plan; open questions; tracking and changelog. Not in scope: Core, Air, Air Hub pages; X01 itself (KEY-O-10 only records the dependency).
Alternatives
章节标题：“Alternatives”- B. STM32G0B1CE + pre-certified BLE module. Keeps ≤5 mA and FDCAN; two firmware images and a UART protocol between them; BOM adds one module. Choose this if the 5 mA target or CAN FD headroom matters more than a single image.
- C. TI CC2745R10-Q1 or NXP KW45. Technically the best single chip (idle ~1.5–2 mA, CAN FD, HSM, automotive grade) but needs chip-down RF design, full radio certification and a vendor toolchain that nothing else in the line uses.
- D. No radio in Key. The phone talks to Mate or Air Hub, which already have Wi-Fi and BLE and already hold the X01 hub role; for boats without either, a BLE-to-CAN service dongle carried by the installer. Key stays on the non-wireless compliance row and keeps its role as a radio-free fallback. This is the smallest change and should be rejected explicitly if the owner wants the radio in every Key.
Annotations
章节标题：“Annotations”- 2026-09-28 (owner): "这个是做 key 产品选型芯片" and "需要无线去配置和升级". Plan written with option A recommended.
- 2026-09-28 (owner): "可以放宽、为什么我们不用 air 同款芯片". Static-current relaxation accepted. Option E (nRF54L15 + SPI CAN controller) added and made the recommendation.
- 2026-09-28 (owner): "key 不是为了省电，他是电源长链接，后续如果需要 485 或者 can 哪个更方便， 另外价格如何". Wired-bus comparison and LCSC prices added; recommendation changed to the ESP32-C6 module.
- 2026-09-28 (owner): asked how to add output-circuit indicators and what to build digital outputs from. Answered in chat: protected 40 V-class high-side switches (TI TPS4H160-Q1 / TPS2H160-Q1, LCSC $1.1–2.0) for ≤1 A channels, indicators on spare channels of the I2C LED driver showing diagnosed state; larger loads stay on Core. Recorded as open item KEY-O-12 because it changes KEY-01 (four wires) and the Key / Core boundary; not part of this plan's edits until the owner defines the loads.
- 2026-09-28 (owner): "这个是微电流不需要 core 里面大电流 do". The outputs are signal-level,
so the Core boundary is not at issue. Proposed default for KEY-O-12: four high-side channels,
≤0.25 A each, one TI TPS4H160-Q1 (quad, 3.4–40 V, current limit, short-circuit and
over-temperature protection, diagnostics; LCSC $1.31–2.00) or four TPS1H000-Q1 ($0.56 each)
when channels must be placed apart; photo-MOS relays (about $0.60–0.71 per channel) only if
an isolated dry contact is required. Unprotected driver arrays (TBD62783, ULN2003) are not
proposed because a shorted output wire must not take the panel down. Awaiting the owner's
channel count, per-channel current and load type, and
proceed. - 2026-09-28 (owner): "是对 key 按钮关联通道的状态做 led 标识". The request was for the per-key status LED of the bound channel, not an external output. That is already required by KEY-04 (per-key RGB status plus white / red legend), SYS-02 (render Core read-back only), KEY-08, KEY-11 and KEY-12, and is driven by the I2C constant-current LED driver in the design appendix. KEY-O-12 and the high-side switch proposal are withdrawn; KEY-01 stays at four functional wires. The design appendix edit keeps the LED driver on the ESP32-C6 I2C bus and records LP5036 and IS31FL3236A (36 channels) as lower-cost alternatives to LP5024.
- 2026-09-28 (owner): "假设 40 路呢". Read as 40 keys, each bound to one channel: 40 inputs and 200 LED channels at five per key. Answered in chat and to be written into design §2.2 with this plan: inputs on three 16-bit I2C expanders with interrupt (AW9523B / XL9555 / TCA9555, LCSC $0.33–0.87 each) because the ESP32-C6 cannot take 40 independent key lines; LEDs on six 36-channel constant-current drivers (IS31FL3236A $0.52 or LP5036 $0.93 each, I2C address count to be checked, second bus or mux if needed), or four drivers if the white / red legend backlight is driven per zone instead of per key (a reading of KEY-04 the owner must confirm), or one matrix driver (IS31FL3741A, $3.49) when board area rules. Backlight budget to be given as base plus per-key increment under KEY-05 / KEY-O-07.
- 2026-09-28 (owner): asked whether one LED can show different states. Answered: yes, one RGB
LED encodes state by colour, brightness and blink rhythm, which SYS-02, KEY-08, KEY-11 and
KEY-12 already require. A further option, one RGB LED per key serving as legend backlight and
status at once (three channels per key, 120 for 40 keys), is recorded for KEY-O-05 because it
changes the optics and the reading of KEY-04; not adopted by this plan. Awaiting
proceed.