feat(esm): ESM driver implementation and host unit tests #78
No reviewers
Labels
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
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
opendutchsolutions.public/hal_awr6843!78
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/77-esm-driver"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
Adds
hal/mss/esm/hal_esm.c/.h(+private/esm_types.h) — the ESM driver: pending-error clear on init, routing ESM's high/low priority lines through the VIM, per-channel Group 1 IRQ enable/disable viaESMIESR/ESMIECR, and the two priority IRQ handlers decodingESMIOFFHR/ESMIOFFLRto a weak, application-overridablehal_esm_irq_handler()hook. Also landshal/mss/vim/hal_vim.h(declarations only —hal_vim.cis a separate future issue) sincehal_esm_init()callshal_vim_set_priority()/hal_vim_enable().Why
Continues the driver-implementation phase started by GPIO (#75/#76). ESM is on-by-default safety/error-signaling infrastructure most other peripherals eventually route errors through, so landing it early (with VIM's header-only dependency) keeps later drivers unblocked.
Related Issue
Closes #77
Type of Change
Impact Assessment
Testing
testing/mss/unit/hal_functionality/test_esm_functionallocally (15 test cases, 90 assertions, all passing) alongside the full existingctestsuite (165/165 passing, no regressions); ran a full MISRA C:2025 pass (0 unsuppressed findings, no new-Dflag needed since ESM is on-by-default viaDISABLE_ESM_MODULE); sanity-checked by shiftinghal_esm_enable_irq()'sESMIESR1write by one bit, confirming the test suite fails, then reverting.PR Size
Size justification / exemption (if L or XL):
949 raw lines across 6 files, all genuinely hand-reviewed (no mechanically-generated umbrella content this time, unlike GPIO's PR). Not split further because the three pieces don't decompose into independently-reviewable sub-PRs: the driver (
hal_esm.c/.h, 329 lines) is meaningless without its comprehensive Catch2 spec (test_esm.c, 315 lines, covering both IRQ handlers' channel-decode logic plus the VIM-routing calls via FFF fakes), and both needhal_vim.h's declarations (141 lines) to even compile, sincehal_esm_init()calls two of its functions.esm_types.h's 155-line channel table is TI-cross-checked data, not hand-composed logic.Checklist
type(scope): descriptionconvention withRelates to #<issue>footerSummary
hal/mss/esm/hal_esm.c/.h: ESM driver (init/VIM routing, IRQ enable/disable, priority IRQ handlers)hal/mss/esm/private/esm_types.h: ESM channel enum, cross-checked against TI'ssys_common_xwr68xx_mss.h— found and fixed two genuine omissions: channels 21 (MCANB_RAM_FATAL_ERR) and 33 (MCANB_RAM_REPAIR_ERR) were misclassified as unassigned gaps in the prior draft and are real assigned sources in TI's tablehal/mss/vim/hal_vim.h: VIM driver header (declarations only, no implementation yet)testing/mss/unit/hal_functionality/test_esm.c(+CMakeLists.txt): Catch2 functional test suite, using FFF fakes for the two VIM calls