feat: CMSIS-compliant register description for the AWR6843AOP

hoogv commented

2026-07-21 14:04:07 +00:00

(Migrated from codeberg.org)

Description

hal/registers/component/*.h and hal/registers/instance/*.h are hand-rolled, struct-based register definitions that loosely follow CMSIS conventions (__IO/__I/__O qualifiers, packed structs per peripheral), but there is no actual CMSIS device support package behind them. Two gaps in particular:

ARM doesn't publish an official CMSIS-Core header for Cortex-R the way it does core_cm*.h for Cortex-M, so this project never vendored one — as a result, every component header (see hal/registers/component/esm.h) locally redefines the __I/__O/__IO access-permission qualifiers itself instead of pulling them from one shared header.
There is no CMSIS-SVD (or equivalent machine-readable) register map for the AWR6843AOP. hal/registers/awr6843aop.h and the component/instance headers were authored by hand against the AWR6843 TRM (SWRU520E) and cross-checked against TI's own CSL headers (see testing/mss/unit/ti_hal_comparison), but nothing produces or validates against a standard device description.

Use Case / Rationale

As a firmware developer, I need one canonical, de-duplicated source of the CMSIS access-qualifier macros instead of every component header redefining __I/__O/__IO itself, so there's a single place to fix or extend core conventions.

As a developer integrating this HAL with IDE/debug tooling (VS Code Cortex-Debug, Keil, PyOCD/OpenOCD), I need a CMSIS-SVD description of the AWR6843AOP register map so I get live peripheral register views while debugging instead of manually computing addresses.

As a QMS reviewer, I need the hand-rolled register structs cross-checked against a single authoritative machine-readable source, in addition to the existing by-hand TI CSL comparison, for stronger register-definition traceability.

User Stories

As a developer, I want a shared core/qualifier header (e.g. core_cr4f.h) so hal/registers/component/*.h stop each redefining __I/__O/__IO locally.
As a developer, I want a CMSIS-SVD XML file for the AWR6843AOP so my debugger can show live peripheral register state during development.
As a QMS reviewer, I want the hand-rolled register struct definitions validated against the SVD in addition to the existing TI CSL comparison tests, for stronger traceability.
As a downstream integrator, I want this HAL to look and behave like a standard CMSIS device support package, since ARM doesn't publish an official Cortex-R CMSIS core header the way it does for Cortex-M.

Acceptance Criteria

A single shared CMSIS core/qualifier header exists (naming TBD, e.g. hal/registers/core_cr4f.h) and every hal/registers/component/*.h includes it instead of locally redefining __I/__O/__IO
A CMSIS-SVD (or equivalent machine-readable) description of the AWR6843AOP register map exists, covering at minimum the peripherals already hand-rolled under hal/registers/component
The existing hand-rolled register struct definitions are cross-checked against the SVD/CMSIS description, extending testing/mss/unit/ti_hal_comparison the same way it already checks against TI's CSL headers
The SVD/CMSIS description's location and how to regenerate/validate it against future register additions is documented

Functional Impact

Low — touches only register-definition headers, no driver logic changes.

Regulatory Impact

None

QMS Impact

Potential — may formalize a new register-traceability check; needs assessment.

Risk Impact

No — existing risk coverage sufficient.

No response

### Description `hal/registers/component/*.h` and `hal/registers/instance/*.h` are hand-rolled, struct-based register definitions that loosely follow CMSIS conventions (`__IO`/`__I`/`__O` qualifiers, packed structs per peripheral), but there is no actual CMSIS device support package behind them. Two gaps in particular: - ARM doesn't publish an official CMSIS-Core header for Cortex-R the way it does `core_cm*.h` for Cortex-M, so this project never vendored one — as a result, every component header (see `hal/registers/component/esm.h`) locally redefines the `__I`/`__O`/`__IO` access-permission qualifiers itself instead of pulling them from one shared header. - There is no CMSIS-SVD (or equivalent machine-readable) register map for the AWR6843AOP. `hal/registers/awr6843aop.h` and the component/instance headers were authored by hand against the AWR6843 TRM (SWRU520E) and cross-checked against TI's own CSL headers (see `testing/mss/unit/ti_hal_comparison`), but nothing produces or validates against a standard device description. ### Use Case / Rationale As a firmware developer, I need one canonical, de-duplicated source of the CMSIS access-qualifier macros instead of every component header redefining `__I`/`__O`/`__IO` itself, so there's a single place to fix or extend core conventions. As a developer integrating this HAL with IDE/debug tooling (VS Code Cortex-Debug, Keil, PyOCD/OpenOCD), I need a CMSIS-SVD description of the AWR6843AOP register map so I get live peripheral register views while debugging instead of manually computing addresses. As a QMS reviewer, I need the hand-rolled register structs cross-checked against a single authoritative machine-readable source, in addition to the existing by-hand TI CSL comparison, for stronger register-definition traceability. ### User Stories - As a developer, I want a shared core/qualifier header (e.g. `core_cr4f.h`) so `hal/registers/component/*.h` stop each redefining `__I`/`__O`/`__IO` locally. - As a developer, I want a CMSIS-SVD XML file for the AWR6843AOP so my debugger can show live peripheral register state during development. - As a QMS reviewer, I want the hand-rolled register struct definitions validated against the SVD in addition to the existing TI CSL comparison tests, for stronger traceability. - As a downstream integrator, I want this HAL to look and behave like a standard CMSIS device support package, since ARM doesn't publish an official Cortex-R CMSIS core header the way it does for Cortex-M. ### Acceptance Criteria - [x] A single shared CMSIS core/qualifier header exists (naming TBD, e.g. `hal/registers/core_cr4f.h`) and every `hal/registers/component/*.h` includes it instead of locally redefining `__I`/`__O`/`__IO` - [x] A CMSIS-SVD (or equivalent machine-readable) description of the AWR6843AOP register map exists, covering at minimum the peripherals already hand-rolled under `hal/registers/component` - [x] The existing hand-rolled register struct definitions are cross-checked against the SVD/CMSIS description, extending `testing/mss/unit/ti_hal_comparison` the same way it already checks against TI's CSL headers - [x] The SVD/CMSIS description's location and how to regenerate/validate it against future register additions is documented ### Functional Impact Low — touches only register-definition headers, no driver logic changes. ### Regulatory Impact None ### QMS Impact Potential — may formalize a new register-traceability check; needs assessment. ### Risk Impact No — existing risk coverage sufficient. ### Related Issues / PRs _No response_