feat(dma): CMSIS core header, SVD entries, and TI comparison tests #37

Merged
hoogv merged 0 commits from refs/pull/37/head into dev 2026-07-22 10:17:50 +00:00
hoogv commented 2026-07-22 10:12:07 +00:00 (Migrated from codeberg.org)

Lands MSS DMA under the CMSIS register description epic (#4). This one's a bigger jump in scale than ADCBUF/CBUFF/DSS_INTC/DSSREG -- two physically separate register blocks in the same header: Dma (76 control registers) and DmaRam (32-channel control-packet RAM, its own base address). Confirmed with the user up front to keep both in this one PR rather than splitting further.

  • hal/registers/component/dma.h now includes core_cr4f.h instead of a local qualifier redefinition.
  • Two SVD peripheral entries (DMA, DMARAM) added to hal/registers/svd/AWR6843AOP_MSS.svd, cross-checked via new svd_check_dma/svd_check_dmaram ctests.
  • testing/mss/unit/ti_hal_comparison/test_dma.c extended: this file already existed (it's this project's own stated exemplar/template for the whole ti_hal_comparison suite) but only covered Dma. Switched its include from the registers/awr.h aggregator to component/dma.h + instance/dma.h directly (same fix as every other peripheral in this suite -- awr6843aop.h unconditionally includes all 22 peripherals, most not yet landed), and added DmaRam vs TI's DMARAMRegs coverage.

On the SVD entries' scale: given 76+9 registers (several times larger than anything landed so far), the two <peripheral> blocks were generated by a script parsing this project's own header macros (_OFFSET/_RESETVALUE/_Pos/_Msk) rather than hand-transcribed one register at a time -- then spot-checked against the header/TRM afterward, same diligence as every prior peripheral, just applied via script given the register count.

Verified locally: full suite builds and all 21 tests pass. Also sanity-checked that the TI comparison test actually catches drift -- deliberately broke the DMA1 RAM base-address comparison, confirmed it failed, then reverted and confirmed green again.

Closes #9

Lands MSS DMA under the CMSIS register description epic (#4). This one's a bigger jump in scale than ADCBUF/CBUFF/DSS_INTC/DSSREG -- two physically separate register blocks in the same header: `Dma` (76 control registers) and `DmaRam` (32-channel control-packet RAM, its own base address). Confirmed with the user up front to keep both in this one PR rather than splitting further. - `hal/registers/component/dma.h` now includes `core_cr4f.h` instead of a local qualifier redefinition. - Two SVD peripheral entries (`DMA`, `DMARAM`) added to `hal/registers/svd/AWR6843AOP_MSS.svd`, cross-checked via new `svd_check_dma`/`svd_check_dmaram` ctests. - `testing/mss/unit/ti_hal_comparison/test_dma.c` extended: this file already existed (it's this project's own stated exemplar/template for the whole `ti_hal_comparison` suite) but only covered `Dma`. Switched its include from the `registers/awr.h` aggregator to `component/dma.h` + `instance/dma.h` directly (same fix as every other peripheral in this suite -- `awr6843aop.h` unconditionally includes all 22 peripherals, most not yet landed), and added `DmaRam` vs TI's `DMARAMRegs` coverage. **On the SVD entries' scale**: given 76+9 registers (several times larger than anything landed so far), the two `<peripheral>` blocks were generated by a script parsing this project's own header macros (`_OFFSET`/`_RESETVALUE`/`_Pos`/`_Msk`) rather than hand-transcribed one register at a time -- then spot-checked against the header/TRM afterward, same diligence as every prior peripheral, just applied via script given the register count. Verified locally: full suite builds and all 21 tests pass. Also sanity-checked that the TI comparison test actually catches drift -- deliberately broke the DMA1 RAM base-address comparison, confirmed it failed, then reverted and confirmed green again. Closes #9
hoogv self-assigned this 2026-07-23 13:35:02 +00:00
hoogv added this to the Development project 2026-07-23 13:38:58 +00:00
Sign in to join this conversation.
No reviewers
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!37
No description provided.