feat: DSS INTC driver implementation and host unit tests #107

Closed
opened 2026-07-23 18:37:18 +00:00 by hoogv · 0 comments
Owner

Description

Adds hal/dss/intc/hal_dss_intc.c/.h — the C674x DSP's Interrupt Selector driver. The C674x's interrupt architecture has no counterpart to the MSS/R4F's VIM — it's two separate mechanisms, and this driver covers the memory-mapped, host-testable one: the Interrupt Selector, which latches/combines up to 128 SoC-wide system events and lets software program which event lands on which of the 12 usable CPU interrupts (INT4-INT15, via INTMUX1-3). hal_dss_intc_map_event_to_vector()/hal_dss_intc_get_event_for_vector() program/read back that routing; hal_dss_intc_event_flag()/_set()/_clear()/_mask()/_unmask() operate on individual event flags; hal_dss_intc_check_dropped_event()/_clear_dropped_event() handle INTXSTAT drop detection. A second set of functions (hal_dss_intc_enable_vector(), _disable_vector(), _clear_vector_pending(), _set_vector_table(), _enable_global_interrupts(), _disable_global_interrupts()) covers the CPU's own non-memory-mapped interrupt state (IER/ICR/ISTP/CSR.GIE) — these are cl6x-only (TI-compiler __cregister extensions, guarded #if defined(_TMS320C6X)) and absent entirely from the host-test build, since there is no fake-register shim possible for non-addressable compiler registers.

Documents an empirically-confirmed open hardware risk in its top-of-file comment: even with a fully TRM/SPRUFK5A-correct register sequence, a bare hand-rolled ISR (no SYS/BIOS-style dispatcher) has been observed to occasionally mis-dispatch on real AWR6843 silicon — root cause unresolved, flagged as a known risk rather than a solved problem.

Use Case / Rationale

As a firmware developer, I need a hal_dss_intc_* API for DSS-side system-event-to-CPU-vector routing, continuing the DSS-side driver batch (Mailbox, EDMA, VIM, DSS ADCBUF already landed).

As a QMS reviewer, I need a host-native Catch2 test suite (testing/dss/intc/test_dss_intc.c) covering the memory-mapped register API's bounds checking and bit-packing math, runnable in CI without target hardware — the cl6x-only CPU-register functions are outside what a host build can exercise at all, and are excluded from this test suite by the same #if defined(_TMS320C6X) guard the driver itself uses.

Acceptance Criteria

  • hal/dss/intc/hal_dss_intc.c/.h implemented against this project's current hal/registers/component/dss_intc.h/instance/dss_intc.h
  • testing/dss/intc/test_dss_intc.c passes under ctest
  • Sanity-checked by deliberately breaking a register field/formula and confirming the test suite catches it, then reverting

Functional Impact

None — self-contained addition alongside the already-landed Mailbox/EDMA/VIM/DSS-ADCBUF drivers.

Regulatory Impact

None

QMS Impact

None

Risk Impact

No new risk beyond the documented, pre-existing, unresolved hand-rolled-ISR dispatch-reliability caveat this driver's header carries forward from prior hardware investigation — existing risk coverage otherwise sufficient.

Relates to #4, relates to #99, relates to #101, relates to #103, relates to #105

### Description Adds `hal/dss/intc/hal_dss_intc.c`/`.h` — the C674x DSP's Interrupt Selector driver. The C674x's interrupt architecture has no counterpart to the MSS/R4F's VIM — it's two separate mechanisms, and this driver covers the memory-mapped, host-testable one: the Interrupt Selector, which latches/combines up to 128 SoC-wide system events and lets software program which event lands on which of the 12 usable CPU interrupts (INT4-INT15, via `INTMUX1-3`). `hal_dss_intc_map_event_to_vector()`/`hal_dss_intc_get_event_for_vector()` program/read back that routing; `hal_dss_intc_event_flag()`/`_set()`/`_clear()`/`_mask()`/`_unmask()` operate on individual event flags; `hal_dss_intc_check_dropped_event()`/`_clear_dropped_event()` handle `INTXSTAT` drop detection. A second set of functions (`hal_dss_intc_enable_vector()`, `_disable_vector()`, `_clear_vector_pending()`, `_set_vector_table()`, `_enable_global_interrupts()`, `_disable_global_interrupts()`) covers the CPU's own non-memory-mapped interrupt state (IER/ICR/ISTP/CSR.GIE) — these are `cl6x`-only (TI-compiler `__cregister` extensions, guarded `#if defined(_TMS320C6X)`) and absent entirely from the host-test build, since there is no fake-register shim possible for non-addressable compiler registers. Documents an empirically-confirmed open hardware risk in its top-of-file comment: even with a fully TRM/SPRUFK5A-correct register sequence, a bare hand-rolled ISR (no SYS/BIOS-style dispatcher) has been observed to occasionally mis-dispatch on real AWR6843 silicon — root cause unresolved, flagged as a known risk rather than a solved problem. ### Use Case / Rationale As a firmware developer, I need a `hal_dss_intc_*` API for DSS-side system-event-to-CPU-vector routing, continuing the DSS-side driver batch (Mailbox, EDMA, VIM, DSS ADCBUF already landed). As a QMS reviewer, I need a host-native Catch2 test suite (`testing/dss/intc/test_dss_intc.c`) covering the memory-mapped register API's bounds checking and bit-packing math, runnable in CI without target hardware — the `cl6x`-only CPU-register functions are outside what a host build can exercise at all, and are excluded from this test suite by the same `#if defined(_TMS320C6X)` guard the driver itself uses. ### Acceptance Criteria - [ ] `hal/dss/intc/hal_dss_intc.c`/`.h` implemented against this project's current `hal/registers/component/dss_intc.h`/`instance/dss_intc.h` - [ ] `testing/dss/intc/test_dss_intc.c` passes under `ctest` - [ ] Sanity-checked by deliberately breaking a register field/formula and confirming the test suite catches it, then reverting ### Functional Impact None — self-contained addition alongside the already-landed Mailbox/EDMA/VIM/DSS-ADCBUF drivers. ### Regulatory Impact None ### QMS Impact None ### Risk Impact No new risk beyond the documented, pre-existing, unresolved hand-rolled-ISR dispatch-reliability caveat this driver's header carries forward from prior hardware investigation — existing risk coverage otherwise sufficient. ### Related Issues / PRs Relates to #4, relates to #99, relates to #101, relates to #103, relates to #105
hoogv closed this issue 2026-07-23 18:45:23 +00:00
hoogv added this to the Development project 2026-07-23 19:09:27 +00:00
hoogv self-assigned this 2026-07-23 19:09:38 +00:00
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
opendutchsolutions.public/hal_awr6843#107
No description provided.