feat: MCAN driver implementation and host unit tests #97

New issue

Closed

opened 2026-07-23 15:37:43 +00:00 by hoogv · 0 comments

hoogv commented

2026-07-23 15:37:43 +00:00

Owner

Description

Adds hal/mss/mcan/hal_mcan.c/.h — the MCAN (Bosch M_CAN / CAN-FD controller) driver: MEM_INIT_DONE-then-reset-then-CCCR.INIT bring-up sequence (cross-checked against the mmwave SDK's CANFD_open()), nominal bit-timing derivation (fixed 16-time-quantum, 75% sample point) from a requested classic-CAN bit rate, an "accept everything into Rx FIFO 0" global filter configuration, blocking transmit (dedicated Tx buffer 0, decodes PSR.LEC/BO into NACK/bus-error/bus-off status) and blocking receive (Rx FIFO 0, pop-and-acknowledge), and the two raw device handlers (MCAN_LVL0_IRQHandler/MCANB_LVL0_IRQHandler) decoding IR to a weak, application-overridable hal_mcan_irq_handler() hook. Both MCAN instances (MCANA/MCANB) supported.

Deliberately minimal scope (documented in hal_mcan.h's top-of-file comment): only classic CAN frames (no CAN-FD bit-rate switching/long-frame data phase), only standard 11-bit ID acceptance (no extended-ID filtering beyond the single global filter), one Rx FIFO and one set of dedicated Tx buffers (no Tx Event FIFO, no Rx FIFO 1, no dedicated Rx buffers), and no bus-off recovery automation.

Use Case / Rationale

As a firmware developer, I need a hal_mcan_* API for basic classic-CAN transmit/receive, following the same driver pattern established by GPIO, ESM, UART, I2C, SPI, ADCBUF, CBUFF, HWA, DMM, EPWM, and SOC — this is the final driver in the current driver-implementation batch.

As a QMS reviewer, I need a host-native Catch2 test suite (testing/mss/unit/hal_functionality/test_mcan.c) covering the bit-timing derivation math, the bring-up sequence, both transmit/receive paths and their error decoding, and both instances' IRQ handlers, runnable in CI without target hardware.

Acceptance Criteria

hal/mss/mcan/hal_mcan.c/.h implemented against this project's current hal/registers/component/mcan.h/instance/mcan.h
testing/mss/unit/hal_functionality/test_mcan.c passes under ctest
Sanity-checked by deliberately breaking a register field/formula and confirming the test suite catches it, then reverting

Functional Impact

None — self-contained addition alongside the already-landed GPIO/ESM/UART/I2C/SPI/ADCBUF/CBUFF/HWA/DMM/EPWM/SOC drivers.

Regulatory Impact

None

QMS Impact

None

Risk Impact

No — existing risk coverage sufficient.

Relates to #4, relates to #75, relates to #77, relates to #79, relates to #81, relates to #83, relates to #85, relates to #87, relates to #89, relates to #91, relates to #93, relates to #95

### Description Adds `hal/mss/mcan/hal_mcan.c`/`.h` — the MCAN (Bosch M_CAN / CAN-FD controller) driver: MEM_INIT_DONE-then-reset-then-CCCR.INIT bring-up sequence (cross-checked against the mmwave SDK's `CANFD_open()`), nominal bit-timing derivation (fixed 16-time-quantum, 75% sample point) from a requested classic-CAN bit rate, an "accept everything into Rx FIFO 0" global filter configuration, blocking transmit (dedicated Tx buffer 0, decodes PSR.LEC/BO into NACK/bus-error/bus-off status) and blocking receive (Rx FIFO 0, pop-and-acknowledge), and the two raw device handlers (`MCAN_LVL0_IRQHandler`/`MCANB_LVL0_IRQHandler`) decoding IR to a weak, application-overridable `hal_mcan_irq_handler()` hook. Both MCAN instances (MCANA/MCANB) supported. Deliberately minimal scope (documented in `hal_mcan.h`'s top-of-file comment): only classic CAN frames (no CAN-FD bit-rate switching/long-frame data phase), only standard 11-bit ID acceptance (no extended-ID filtering beyond the single global filter), one Rx FIFO and one set of dedicated Tx buffers (no Tx Event FIFO, no Rx FIFO 1, no dedicated Rx buffers), and no bus-off recovery automation. ### Use Case / Rationale As a firmware developer, I need a `hal_mcan_*` API for basic classic-CAN transmit/receive, following the same driver pattern established by GPIO, ESM, UART, I2C, SPI, ADCBUF, CBUFF, HWA, DMM, EPWM, and SOC — this is the final driver in the current driver-implementation batch. As a QMS reviewer, I need a host-native Catch2 test suite (`testing/mss/unit/hal_functionality/test_mcan.c`) covering the bit-timing derivation math, the bring-up sequence, both transmit/receive paths and their error decoding, and both instances' IRQ handlers, runnable in CI without target hardware. ### Acceptance Criteria - [ ] `hal/mss/mcan/hal_mcan.c`/`.h` implemented against this project's current `hal/registers/component/mcan.h`/`instance/mcan.h` - [ ] `testing/mss/unit/hal_functionality/test_mcan.c` passes under `ctest` - [ ] Sanity-checked by deliberately breaking a register field/formula and confirming the test suite catches it, then reverting ### Functional Impact None — self-contained addition alongside the already-landed GPIO/ESM/UART/I2C/SPI/ADCBUF/CBUFF/HWA/DMM/EPWM/SOC drivers. ### Regulatory Impact None ### QMS Impact None ### Risk Impact No — existing risk coverage sufficient. ### Related Issues / PRs Relates to #4, relates to #75, relates to #77, relates to #79, relates to #81, relates to #83, relates to #85, relates to #87, relates to #89, relates to #91, relates to #93, relates to #95

hoogv referenced this issue from a commit

2026-07-23 15:41:20 +00:00

feat(mcan): MCAN driver implementation and host unit tests

hoogv referenced this issue from a pull request that will close it,

2026-07-23 15:41:47 +00:00

feat(mcan): MCAN driver implementation and host unit tests #98

hoogv closed this issue

2026-07-23 16:06:19 +00:00

hoogv self-assigned this

2026-07-23 19:10:36 +00:00

hoogv added this to the Development project

2026-07-23 19:10:39 +00:00