Surfaced during Phase 2 citation backfill (issue #164, batches 2/6/11). Both are left honestly uncited in .fusa-reqs.json rather than force-cited, per the standing per-batch discipline. Filing separately so they don't get lost in PR descriptions/memory once #164 closes.
1. REQ-ACF-012 — RCP_ACF_MTV_UNCERTAIN
rcp_acf_gbb_is_timed() returns true only when info.mtv == RCP_ACF_MTV_VALID. There's a third enum value, RCP_ACF_MTV_UNCERTAIN, whose TC18 basis was not found during batch 2 (PR #172) review of §11.2.1 Figure 7/Table 4. Needs someone to read the full mtv-bit definition in TC18 (not just the table cited so far) and determine: is MTV_UNCERTAIN a real third wire state, or an implementation-only convenience value with no wire representation? Either answer resolves the citation; right now it's just unresolved.
Source: src/acf.c / include/rcp/acf.h, rcp_acf_gbb_is_timed().
2. RCP_EP_PWM_IN_NO_SIGNAL sentinel (REQ-PWM-047, REQ-PWM-054, and the equivalent ADC entries)
TC18 Table 27 defines PWM_IN_NO_SIGNAL as a numbered wire error code (§ error-response err field). c-RCP's PWM_IN and ADC endpoints additionally use RCP_EP_PWM_IN_NO_SIGNAL (0xFFFF) as a payload sentinel value inside an otherwise-normal Read Response. TC18 does not appear to define a payload-sentinel convention anywhere — only the Table 27 error-code path. Two ways this could resolve:
- The sentinel is a c-RCP-only convenience (not a TC18 concept) — in which case these requirements should stay uncited permanently as an implementation detail, not a gap.
- TC18 has a payload-sentinel convention elsewhere (e.g. in the PWM_IN or ADC chapter's worked examples) that wasn't found during batches 6/11's citation passes — in which case it's a real citation gap.
Needs a full read of §13.7.6 (PWM_IN) and §13.7.9 (ADC) prose, not just the tables already cited, to settle which case applies. Until then these stay uncited, consistent with the standing "don't force-fit" discipline (see REQ-ACF-012 precedent above, which is the same class of open question).
Related: #163 (Table 27 error-code wiring — PWM_IN_NO_SIGNAL is also one of the still-unwired codes there, so these two issues may turn out to share one investigation), #164 (citation backfill, where both were found).
Surfaced during Phase 2 citation backfill (issue #164, batches 2/6/11). Both are left honestly uncited in
.fusa-reqs.jsonrather than force-cited, per the standing per-batch discipline. Filing separately so they don't get lost in PR descriptions/memory once #164 closes.1.
REQ-ACF-012—RCP_ACF_MTV_UNCERTAINrcp_acf_gbb_is_timed()returns true only wheninfo.mtv == RCP_ACF_MTV_VALID. There's a third enum value,RCP_ACF_MTV_UNCERTAIN, whose TC18 basis was not found during batch 2 (PR #172) review of §11.2.1 Figure 7/Table 4. Needs someone to read the fullmtv-bit definition in TC18 (not just the table cited so far) and determine: isMTV_UNCERTAINa real third wire state, or an implementation-only convenience value with no wire representation? Either answer resolves the citation; right now it's just unresolved.Source:
src/acf.c/include/rcp/acf.h,rcp_acf_gbb_is_timed().2.
RCP_EP_PWM_IN_NO_SIGNALsentinel (REQ-PWM-047,REQ-PWM-054, and the equivalent ADC entries)TC18 Table 27 defines
PWM_IN_NO_SIGNALas a numbered wire error code (§ error-responseerrfield). c-RCP's PWM_IN and ADC endpoints additionally useRCP_EP_PWM_IN_NO_SIGNAL(0xFFFF) as a payload sentinel value inside an otherwise-normal Read Response. TC18 does not appear to define a payload-sentinel convention anywhere — only the Table 27 error-code path. Two ways this could resolve:Needs a full read of §13.7.6 (PWM_IN) and §13.7.9 (ADC) prose, not just the tables already cited, to settle which case applies. Until then these stay uncited, consistent with the standing "don't force-fit" discipline (see
REQ-ACF-012precedent above, which is the same class of open question).Related: #163 (Table 27 error-code wiring —
PWM_IN_NO_SIGNALis also one of the still-unwired codes there, so these two issues may turn out to share one investigation), #164 (citation backfill, where both were found).