fix: correct PWM_OUT/ISELED/MDIO/ADC wire formats (#70, #71, #72, #77)

.fusa-reqs.json

@@ -2986,16 +2986,16 @@
     },
     {
       "id": "REQ-PWM-002",
-      "title": "PWM_OUT write semantics: generic combinators applied independently",
-      "text": "rcp::pwm::PwmOutEndpoint::handle_write shall apply Replace/Or/And/Xor to `period` and `active_duration` independently via rcp::endpoint::apply_bitmask_write.",
+      "title": "PWM_OUT write semantics: Replace applies directly",
+      "text": "rcp::pwm::PwmOutEndpoint::handle_write shall apply WriteSemantics::Replace by directly assigning `period` and `active_duration` from the request, matching the single write behavior the OPEN Alliance TC18 Remote Control Protocol Specification's PWM_OUT request-handling section describes.",
       "standard": "iso26262",
       "level": "ASIL-B",
       "asil": "ASIL-B"
     },
     {
       "id": "REQ-PWM-003",
-      "title": "PWM_OUT write semantics: saturating Add/Subtract shared with GPIO",
-      "text": "rcp::pwm::PwmOutEndpoint::handle_write shall apply the saturating Add/Subtract rule to `period` and `active_duration` independently, clamping instead of wrapping, via the same rcp::endpoint saturation helpers rcp::gpio::apply_gpio_write uses.",
+      "title": "PWM_OUT write semantics: Or/And/Xor/Add/Subtract rejected as non-combinable",
+      "text": "rcp::pwm::PwmOutEndpoint::handle_write shall return rcp::endpoint::EndpointErrc::non_combinable_write_semantics without modifying its state for WriteSemantics::Or, ::And, ::Xor, ::Add, and ::Subtract, since the specification's PWM_OUT request-handling section defines no bitmask/saturating-write combination against the endpoint's previous period/active values.",
       "standard": "iso26262",
       "level": "ASIL-B",
       "asil": "ASIL-B"
@@ -3226,16 +3226,16 @@
     },
     {
       "id": "REQ-ISELED-002",
-      "title": "ISELED Instruction/Address/Data request and Address/Data(/CRC) response shape",
-      "text": "rcp::iseled::IseledEndpoint::transact shall record the exact IseledRequest (instruction/address/data) and IseledResponse (address/data/optional native_crc) fields passed to it, retrievable via last_request()/last_response().",
+      "title": "ISELED Instruction/Address/Data request and Address/Data response shape",
+      "text": "rcp::iseled::IseledEndpoint::transact shall record the exact IseledRequest (instruction/address/data) and IseledResponse (address/data) fields passed to it, retrievable via last_request()/last_response(), for a request and response whose fields fit their documented wire widths.",
       "standard": "iso26262",
       "level": "ASIL-B",
       "asil": "ASIL-B"
     },
     {
       "id": "REQ-ISELED-003",
-      "title": "ISELED native CRC is additional to, not a replacement for, the general E2E CRC",
-      "text": "rcp::iseled::verify_native_crc shall succeed without error when IseledResponse::native_crc is std::nullopt, shall succeed when native_crc equals compute_native_crc8(crc_coverage_bytes(response)), and shall return IseledErrc::native_crc_mismatch when it does not; this header shall have no dependency on and shall not call into rcp/e2e.hpp.",
+      "title": "ISELED 12-bit address / 12-bit data field-width validation",
+      "text": "rcp::iseled::validate_request shall return IseledErrc::field_out_of_range when instruction exceeds kIseledInstructionMask (4 bits) or address exceeds kIseledFieldMask (12 bits); rcp::iseled::validate_response shall return IseledErrc::field_out_of_range when address or data exceeds kIseledFieldMask (12 bits); rcp::iseled::IseledEndpoint::transact shall propagate either failure without recording the request/response or firing TransferComplete.",
       "standard": "iso26262",
       "level": "ASIL-B",
       "asil": "ASIL-B"
@@ -3266,24 +3266,24 @@
     },
     {
       "id": "REQ-MDIO-002",
-      "title": "MDIO address-range validation",
-      "text": "rcp::mdio::validate_request shall return MdioErrc::phy_address_out_of_range for phy_address > kMaxPhyAddress, MdioErrc::device_or_reg_out_of_range for device_or_reg > kMaxDeviceOrRegField, and shall accept every field at or below its own bound.",
+      "title": "MDIO mdio_payload width validation per mdio_mode",
+      "text": "rcp::mdio::payload_width_bits shall return 16 for MdioMode::MmdSingleWord, MdioMode::MmdMultiWord, and MdioMode::MmsSingleWord regardless of mms_is_0_or_1, and shall return 32 for MdioMode::MmsMultiWord only when mms_is_0_or_1 is true (16 otherwise); rcp::mdio::validate_request shall return MdioErrc::payload_exceeds_mode_width when mdio_payload exceeds that width and shall accept every payload at or below it.",
       "standard": "iso26262",
       "level": "ASIL-B",
       "asil": "ASIL-B"
     },
     {
       "id": "REQ-MDIO-003",
-      "title": "MDIO Clause22 flat register write-then-read round-trip",
-      "text": "rcp::mdio::MdioEndpoint::handle_request shall, for MdioClause::Clause22, return the value most recently written to a given (phy_address, device_or_reg) register on a subsequent read, and shall return 0 for a register that has never been written.",
+      "title": "MDIO register write-then-read round-trip",
+      "text": "rcp::mdio::MdioEndpoint::handle_request shall, for a given (mdio_mode, mdio_address) key, return the value most recently written to that register on a subsequent read, and shall return 0 for a register that has never been written.",
       "standard": "iso26262",
       "level": "ASIL-B",
       "asil": "ASIL-B"
     },
     {
       "id": "REQ-MDIO-004",
-      "title": "MDIO Clause45 device+register addressing is distinct from Clause22's address space",
-      "text": "rcp::mdio::MdioEndpoint::handle_request shall key a Clause45 access on (phy_address, device_or_reg, register_address) such that it never observes a value written via MdioClause::Clause22 at the same phy_address/device_or_reg bit pattern, or vice versa, and shall notify TransferComplete on every request regardless of clause.",
+      "title": "MDIO mdio_mode keeps each mode's register space distinct",
+      "text": "rcp::mdio::MdioEndpoint::handle_request shall key a register access on (mdio_mode, mdio_address) such that it never observes a value written under a different mdio_mode at the same mdio_address, and shall notify TransferComplete on every request regardless of mdio_mode.",
       "standard": "iso26262",
       "level": "ASIL-B",
       "asil": "ASIL-B"

ROADMAP.md

@@ -1665,6 +1665,58 @@ corrected to match, without any behavior change:
   real cross-repo architectural difference, not a naming issue, and is
   intentionally left unresolved here — see issue #45.
 
+### Post-hoc wire-format fix pass (issues #70, #71, #72, #77)
+
+A conformance audit of the milestone 48 (v2.4.0) and milestone 51 (v2.7.0)
+endpoint types found four wire-format/error-identity defects, each verified
+directly against the OPEN Alliance TC18 Remote Control Protocol
+Specification's own figures/tables rather than against the extraction
+summaries milestone 48/51 above were written from:
+
+- `rcp/pwm.hpp` (issue #70): PWM_OUT/PWM_IN's `PwmValue::period`/
+  `active_duration` were `uint32_t` (an 8-byte payload); the spec's "pwmo
+  request format" figure (§13.7.5.3) shows a fixed 4-byte payload — two
+  big-endian 16-bit words, period then active (the milestone 48 field
+  *order* was already correct). Both fields are now `uint16_t`, and
+  `encode_pwm_payload`/`decode_pwm_payload` implement the exact 4-byte wire
+  codec. Separately, `PwmOutEndpoint::handle_write` no longer reuses
+  `rcp::endpoint::apply_bitmask_write`'s GPIO-style 8-way bitmask/
+  saturating-write combinator — the spec's PWM_OUT request-handling section
+  describes only direct value application, not combination against the
+  endpoint's previous state, so only `WriteSemantics::Replace` is honored
+  now; every other write semantics is rejected as non-combinable.
+- `rcp/iseled.hpp` (issue #71): `IseledResponse::address` was a full
+  `uint16_t`, `IseledResponse::data` was an open `std::vector<uint8_t>`, and
+  the header carried an invented 8-bit CRC (polynomial `0x07`) its own prior
+  comment admitted was not from the ISELED standard. The spec's "iseled
+  response format" figure (Figure 41, §13.7.12.3) is explicit: a 12-bit
+  address, a 12-bit `Data[11:0]` value, and an *optional* CRC whose own
+  algorithm/width the ISELED standard (not TC18) defines. `address`/`data`
+  are now range-validated to 12 bits (`kIseledFieldMask`); the invented CRC
+  is removed outright rather than replaced with a differently-sized
+  invented one, since no verified ISELED-standard CRC algorithm is
+  available in this codebase — see issue #71 discussion.
+- `rcp/mdio.hpp` (issue #72): the header modeled an invented IEEE 802.3
+  Clause 22/Clause 45 PHY-addressing scheme with no basis in the spec's own
+  MDIO section. Rebuilt around the spec's actual `mdio_mode`/
+  `mdio_address`/`mdio_payload` model (Figure 42 + Table 57, §13.7.13.3):
+  a 2-bit mode selector, an opaque address field ("as per IEEE & OA SPI
+  spec"), and a payload whose width is 16 bits except for MMS
+  multiple-(double-)word access to MMS0/MMS1, which is 32 bits.
+- `rcp/adc.hpp` (issue #77): ADC sample/result values were `uint32_t`
+  throughout; the spec caps ADC resolution at 16 bits and its response
+  figures show "16 bit ADC value" fields (§13.7.9.1, Figure 32/34) — narrowed
+  to `uint16_t` throughout `AdcEndpoint`/`compute_average`. Separately, the
+  no-signal condition's diagnostic message previously rendered as
+  "ADC_NO_SIGNAL", implying a TC18-defined error code; Table 27 ("Error
+  codes in responses", §12.9.6) has no ADC-specific no-signal entry (the
+  only `*_NO_SIGNAL` code, `PWM_IN_NO_SIGNAL` = 9, belongs to PWM_IN) — the
+  message no longer claims that identity.
+
+None of these four are wire-format changes to any *other* endpoint type or
+to the shared AVTPDU/ACF framing; `rcp/endpoint.hpp`,
+`rcp/regmap.hpp`, and every other endpoint header are unmodified.
+
 ---
 ### Appendix A — Legacy Roadmap (v0.1.0–v1.11, superseded)
 ---