feat(dmm): CMSIS core header and SVD entry for the DMM peripheral #44
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!44
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "refs/pull/44/head"
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?
Lands DMM (Data Modification Module) under the CMSIS register description epic (#4).
hal/registers/component/dmm.hnow includescore_cr4f.hinstead of a local qualifier redefinition.DMMSVD peripheral entry is added tohal/registers/svd/AWR6843AOP_MSS.svd, cross-checked via a newsvd_check_dmmctest.No TI comparison test -- unlike every other peripheral landed so far, DMM has no TI CSL header in either available mmWave SDK install (confirmed genuinely absent, not just unindexed) and not even a base-address macro in
sys_common_xwr68xx_mss.h.component/dmm.h's own top-of-file comment already documents this as a TRM-only transcription with no independent source to cross-check against.Given the register count (24, several with a full 18-bit-per-source shared layout across
DMMINTSET/CLR/LVL/FLG, plus 9 near-identical per-pinPC0-8registers), the SVD entry was generated by a script parsing this project's own header macros -- same approach used for DMA (#37) -- spot-checked against the header/TRM afterward.Found and fixed a real gap in
tools/svd/check_svd.pyitself: several of DMM's single-bit fields (e.g.DMMPC0'sSYNCFUNC/CLKFUNC/ENAFUNC) only get a_Mskmacro with a literal bit-shift, no companion_Posmacro at all -- this project's own macro-generation convention only emits_Posfor multi-bit fields, since a single-bit field's position is already fully expressed by its_Mskshift. The checker only recognized_Pos-declared fields, so it reported these as missing entirely. Fixed by also recognizing the_Msk-with-literal-shift pattern.Verified locally:
svd_check_*+ 19ti_hal_comparison, unaffected)._Pos-based path.bitOffsetinto the SVD and confirming the checker catches it, then reverted.Closes #11