opendutchsolutions.public/hal_awr6843
1
0
Fork 0
Code Issues 1 Pull requests Projects 1 Releases Packages Wiki Activity Actions

feat(pinmux): MSS IOMUX/pinmux driver implementation and host unit tests #119

Merged
hoogv merged 1 commit from feat/118-mss-pinmux-driver into dev 2026-07-23 20:55:59 +00:00
Conversation 0 Commits 1 Files changed 15 +464 -2
hoogv commented 2026-07-23 20:55:49 +00:00
Owner
Copy link

Description

Adds hal/mss/pinmux/hal_pinmux.c/.h for MSS_IOMUX (base address 0xFFFFEA00) — a genuinely missing layer this HAL had no coverage for at all: every pin on this device is individually muxed via a 49-entry PADxx_CFG_REG array behind a kick-register write-protect mechanism (IOCFGKICK0/IOCFGKICK1), and neither hal_gpio.c nor any peripheral driver in this HAL touches it. Confirmed missing the hard way: a downstream barebones MSS example found that neither GPIO output nor UART TX/RX reached their physical pads on real AWR6843 hardware, because nothing in this HAL ever routed them there.

Register layout cross-checked against two independent sources that agree exactly:

  • TI's own official CSL header, mmwave_sdk_03_06_02_00-LTS/packages/ti/drivers/pinmux/include/reg_pinmux.h.
  • A sibling downstream project's own register header/driver, independently confirmed working via real hardware bring-up on this exact board.

The IOCFGKICK0/IOCFGKICK1 unlock/lock magic values have no register-level documentation in either source (both explicitly note they were recovered from TI's own mmWave SDK by observation) — carried forward as-is, flagged as such in the driver's own comments rather than silently treated as fully verified.

Also removes the stale MSS_IOMUX_BASE_ADDRESS placeholder from awr6843aop.h (left over from the original register-description epic, "no typed peripheral pointer exists until a component header is written") — now superseded by a real component/instance header pair, which independently confirms the exact same base address that placeholder already had.

Why

Fixes a real, confirmed-on-hardware gap blocking a downstream barebones MSS example: without pinmux, no other driver in this HAL can actually reach its physical pins.

Related Issue

Closes #118

Type of Change

  • New feature
  • Bug fix / nonconformity resolution

Impact Assessment

  • Functional impact: Fixes a real, confirmed-on-hardware gap — GPIO and UART pins were never actually routed to their intended function by this HAL, only configured at the peripheral-internal level.
  • Regulatory impact: None.
  • QMS impact: None.
  • Risk impact: The undocumented IOCFGKICK0/IOCFGKICK1 magic values are a genuine, carried-forward risk note (not derived from a register field description this project has direct access to) — flagged explicitly rather than silently treated as fully verified.

Testing

  • CI pipeline passes (compile, unit tests, integration tests, static analysis)
  • Manually tested: built and ran testing/mss/unit/hal_functionality/test_pinmux locally (5 test cases, 19 assertions, all passing) alongside the full existing ctest suite (403/403 passing, no regressions); ran a full MISRA C:2025 pass (0 unsuppressed findings, -DENABLE_PINMUX_MODULE added); reformatted and re-verified against the exact clang-format 18.1.3 the CI runner uses. Sanity-checked by changing the pad-index bounds check from >= to > (off-by-one, allowing an out-of-range write), confirming the test suite fails (1 assertion), then reverting.
  • No regressions observed in related areas

PR Size

  • L (150–300 lines) — justification required below

Size justification / exemption (if L or XL):

464 raw lines across 15 files, all hand-reviewed (no mechanically-generated content). The register description (iomux.h component/instance, 198 lines) and the driver+test (hal_pinmux.c/.h + test_pinmux.c, 233 lines) don't decompose into independently-reviewable sub-PRs — this project's established pattern lands a register description alongside its first consuming driver when the peripheral is small and focused, same as several earlier DSS drivers this session. The remaining files are small CMake/Kconfig/MISRA wiring diffs.

Checklist

  • Commit messages follow type(scope): description convention with Relates to #<issue> footer
  • PR template filled in completely
  • No unverified external binaries introduced (see QMS-GITFLOW-001 Binary Security section)
  • All commits leave the codebase in a compilable, passing-tests state (Commit Integrity Rule)

Summary

  • hal/registers/component/iomux.h / instance/iomux.h: MSS_IOMUX register description (49-entry PADxx_CFG_REG array, USERMODEEN/PADGLBLCFGREG/IOCFGKICK0/IOCFGKICK1)
  • hal/mss/pinmux/hal_pinmux.c/.h: hal_pinmux_set_pin_function() — unlock/write/re-lock sequence with bounds checking
  • hal/registers/awr6843aop.h: wires IOMUX typed macro in both assembly and C variants; removes the now-superseded MSS_IOMUX_BASE_ADDRESS placeholder
  • testing/mss/unit/hal_functionality/test_pinmux.c (+ CMakeLists.txt): Catch2 functional test suite. No naming collision.
  • testing/support/fakes/registers/awr.h / hw_fakes.c: new fake_iomux register shim
  • zephyr/Kconfig / zephyr/CMakeLists.txt / hal/util/hal_config_mss.h / template/hal_config_mss_template.h: HAL_AWR6843_PINMUX Kconfig option and ENABLE_PINMUX_MODULE bridge
  • tools/misra/run_misra.sh: -DENABLE_PINMUX_MODULE added
## Description Adds `hal/mss/pinmux/hal_pinmux.c`/`.h` for `MSS_IOMUX` (base address `0xFFFFEA00`) — a genuinely missing layer this HAL had no coverage for at all: every pin on this device is individually muxed via a 49-entry `PADxx_CFG_REG` array behind a kick-register write-protect mechanism (`IOCFGKICK0`/`IOCFGKICK1`), and neither `hal_gpio.c` nor any peripheral driver in this HAL touches it. Confirmed missing the hard way: a downstream barebones MSS example found that neither GPIO output nor UART TX/RX reached their physical pads on real AWR6843 hardware, because nothing in this HAL ever routed them there. Register layout cross-checked against two independent sources that agree exactly: - TI's own official CSL header, `mmwave_sdk_03_06_02_00-LTS/packages/ti/drivers/pinmux/include/reg_pinmux.h`. - A sibling downstream project's own register header/driver, independently confirmed working via real hardware bring-up on this exact board. The `IOCFGKICK0`/`IOCFGKICK1` unlock/lock magic values have no register-level documentation in either source (both explicitly note they were recovered from TI's own mmWave SDK by observation) — carried forward as-is, flagged as such in the driver's own comments rather than silently treated as fully verified. Also removes the stale `MSS_IOMUX_BASE_ADDRESS` placeholder from `awr6843aop.h` (left over from the original register-description epic, "no typed peripheral pointer exists until a component header is written") — now superseded by a real component/instance header pair, which independently confirms the exact same base address that placeholder already had. ## Why Fixes a real, confirmed-on-hardware gap blocking a downstream barebones MSS example: without pinmux, no other driver in this HAL can actually reach its physical pins. ## Related Issue Closes #118 ## Type of Change - [x] New feature - [x] Bug fix / nonconformity resolution ## Impact Assessment - **Functional impact:** Fixes a real, confirmed-on-hardware gap — GPIO and UART pins were never actually routed to their intended function by this HAL, only configured at the peripheral-internal level. - **Regulatory impact:** None. - **QMS impact:** None. - **Risk impact:** The undocumented `IOCFGKICK0`/`IOCFGKICK1` magic values are a genuine, carried-forward risk note (not derived from a register field description this project has direct access to) — flagged explicitly rather than silently treated as fully verified. ## Testing - [x] CI pipeline passes (compile, unit tests, integration tests, static analysis) - [x] Manually tested: built and ran `testing/mss/unit/hal_functionality/test_pinmux` locally (5 test cases, 19 assertions, all passing) alongside the full existing `ctest` suite (403/403 passing, no regressions); ran a full MISRA C:2025 pass (0 unsuppressed findings, `-DENABLE_PINMUX_MODULE` added); reformatted and re-verified against the exact clang-format 18.1.3 the CI runner uses. Sanity-checked by changing the pad-index bounds check from `>=` to `>` (off-by-one, allowing an out-of-range write), confirming the test suite fails (1 assertion), then reverting. - [x] No regressions observed in related areas ## PR Size - [x] L (150–300 lines) — justification required below **Size justification / exemption (if L or XL):** 464 raw lines across 15 files, all hand-reviewed (no mechanically-generated content). The register description (`iomux.h` component/instance, 198 lines) and the driver+test (`hal_pinmux.c`/`.h` + `test_pinmux.c`, 233 lines) don't decompose into independently-reviewable sub-PRs — this project's established pattern lands a register description alongside its first consuming driver when the peripheral is small and focused, same as several earlier DSS drivers this session. The remaining files are small CMake/Kconfig/MISRA wiring diffs. ## Checklist - [x] Commit messages follow `type(scope): description` convention with `Relates to #<issue>` footer - [x] PR template filled in completely - [x] No unverified external binaries introduced (see QMS-GITFLOW-001 Binary Security section) - [x] All commits leave the codebase in a compilable, passing-tests state (Commit Integrity Rule) ## Summary - `hal/registers/component/iomux.h` / `instance/iomux.h`: MSS_IOMUX register description (49-entry `PADxx_CFG_REG` array, `USERMODEEN`/`PADGLBLCFGREG`/`IOCFGKICK0`/`IOCFGKICK1`) - `hal/mss/pinmux/hal_pinmux.c`/`.h`: `hal_pinmux_set_pin_function()` — unlock/write/re-lock sequence with bounds checking - `hal/registers/awr6843aop.h`: wires `IOMUX` typed macro in both assembly and C variants; removes the now-superseded `MSS_IOMUX_BASE_ADDRESS` placeholder - `testing/mss/unit/hal_functionality/test_pinmux.c` (+ `CMakeLists.txt`): Catch2 functional test suite. No naming collision. - `testing/support/fakes/registers/awr.h` / `hw_fakes.c`: new `fake_iomux` register shim - `zephyr/Kconfig` / `zephyr/CMakeLists.txt` / `hal/util/hal_config_mss.h` / `template/hal_config_mss_template.h`: `HAL_AWR6843_PINMUX` Kconfig option and `ENABLE_PINMUX_MODULE` bridge - `tools/misra/run_misra.sh`: `-DENABLE_PINMUX_MODULE` added
feat(pinmux): MSS IOMUX/pinmux driver implementation and host unit tests
All checks were successful
lint / clang-format (pull_request) Successful in 10s
Details
tests / host-tests (pull_request) Successful in 47s
Details
lint / clang-format (push) Successful in 10s
Details
lint / misra (pull_request) Successful in 1m12s
Details
tests / host-tests (push) Successful in 47s
Details
lint / misra (push) Successful in 1m12s
Details
dae407f7d7
 
Adds hal/mss/pinmux/hal_pinmux.c/.h for MSS_IOMUX, a genuinely
missing layer this HAL had no coverage for at all: every pin on this
device is individually muxed via a 49-entry PADxx_CFG_REG array
behind a kick-register write-protect mechanism
(IOCFGKICK0/IOCFGKICK1), and neither hal_gpio.c nor any peripheral
driver touches it. Confirmed missing on real hardware: neither GPIO
output nor UART TX/RX reached their physical pads on a downstream
barebones example, because nothing in this HAL ever routed them
there.

Register layout cross-checked against TI's own official CSL header
(reg_pinmux.h) and an independently hardware-confirmed sibling
project's own register header/driver -- both agree exactly. The
IOCFGKICK0/IOCFGKICK1 unlock/lock magic values have no register-level
documentation in either source (both recovered them from TI's mmWave
SDK by observation); carried forward as-is, flagged as such.

Removes the stale MSS_IOMUX_BASE_ADDRESS placeholder from
awr6843aop.h, now superseded by a real component/instance header
pair -- independently confirms the same base address this project's
own original register-description epic had already found.

Closes #118

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
hoogv added this to the Development project 2026-07-23 20:56:04 +00:00
hoogv self-assigned this 2026-07-23 20:56:08 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
  
Category
App
 Application/user-facing software related

  
Category
Documentation
 Documentation, user guides, IFU

  
Category
Firmware
 Firmware/embedded software related

  
Category
Hardware
 Hardware/PCB related

  
Category
Qms
 QMS/process documentation

  
PR_Size
L
 150–300 lines (requires justification)

  
PR_Size
M
 50–150 lines (standard change)

  
PR_Size
S
 10–50 lines (small fix)

  
PR_Size
XL
 > 500 lines

  
PR_Size
XS
 < 10 lines (typo, single value)

  
Priority
Critical
 The priority is critical

  
Priority
High
 The priority is high

  
Priority
Low
 The priority is low

  
Priority
Medium
 Medium priority

  
Priority
Very Low Priority
 Very Low Priority

  
Size
Epic
 Large initiative spanning multiple features

  
Size
Feature
 Complete user-facing functionality

  
Size
Task
 Discrete work item or subtask

  
Status
Blocked
 Blocked waiting for input/approval

  
Status
Draft
 Draft/WIP pull request

  
Status
Needs-review
 Ready for review

  
Team
Board
 Board/leadership decisions, strategy

  
Team
Dev
 UX & development/implementation

  
Team
Management
 Management/QMS/process oversight

  
Type
Bug
 Not working as intended (nonconformity)

  
Type
Capa
 Corrective/preventive action

  
Type
Improvement
 Enhancement/optimization of existing feature

  
Type
New-feature
 New functionality

  
Type
Regulatory
 Regulatory/standards change

  
Type
Usability
 User feedback/observation

No labels
Category
App
Category
Documentation
Category
Firmware
Category
Hardware
Category
Qms
PR_Size
L
PR_Size
M
PR_Size
S
PR_Size
XL
PR_Size
XS
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Priority
Very Low Priority
Size
Epic
Size
Feature
Size
Task
Status
Blocked
Status
Draft
Status
Needs-review
Team
Board
Team
Dev
Team
Management
Type
Bug
Type
Capa
Type
Improvement
Type
New-feature
Type
Regulatory
Type
Usability
Milestone
Clear milestone
No items
Projects
Clear projects
No items
No project
Development
Assignees
Clear assignees
No assignees
hoogv
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!119
No description provided.