Add basic MCAN driver for MSPM0 #5296

magmastonealex · 2026-01-25T18:59:37Z

This commit implements a simple driver for the MCAN peripheral on MSPM0, supporting both blocking and non-blocking mode.

An example is included for the MSPM0G3107 (the only part I have access to for testing), but this should work on all parts with a CANFD/MCAN peripheral.

As discussed in Matrix - this also configures SYSPLL in a slightly silly way to allow for providing a valid functional clock without requiring an external oscillator. In testing, this is fine at moderate bitrates.

This driver is intended to be a starting point, and does not yet include a variety of useful features for a well-rounded driver. In particular it does not include:

Async operation (in progress, but not yet implemented here)
CAN-FD
Filtering
TX confirmation
More complex clocking
Bitrate calculation
Automatic bus-off recovery

I hope to work towards implementing these features, but I can't commit to any sort of timeline.

This commit implements a simple driver for the MCAN peripheral on MSPM0, supporting both blocking and non-blocking mode. An example is included for the MSPM0G3107 (the only part I have access to for testing), but this _should_ work on all parts with a CANFD/MCAN peripheral. This driver is intended to be a starting point, and does not yet include a variety of useful features for a well-rounded driver. In particular it does not include: - Async operation (in progress, but not yet implemented here) - CAN-FD - Filtering - TX confirmation - More complex clocking - Bitrate calculation - Automatic bus-off recovery I hope to work towards implementing these features, but I can't commit to any sort of timeline.

magmastonealex · 2026-01-25T19:00:56Z

embassy-mspm0/Cargo.toml

-mspm0-metapac = { git = "https://github.com/mspm0-rs/mspm0-data-generated/", tag = "mspm0-data-d9f54366c65cec47957065f42fe04542b852a8cd" }
-rand_core = "0.9"
+mspm0-metapac = { git = "https://github.com/mspm0-rs/mspm0-data-generated/", tag = "mspm0-data-566cf58760f60a9126c957ae9b6b3364e46ed595" }
+bitfield = "0.19.4"


bitfield is also used by embassy-net-adin1110 and I couldn't find other similar bitfield crates in use within embassy. This is used to construct some of the fields for message RAM - I'm open to using a different crate if preferable.

magmastonealex · 2026-01-25T19:01:25Z

embassy-mspm0/build.rs

+    match sysctl.version {
+        Some("g350x_g310x_g150x_g110x") | Some("g351x_g151x") => {
+            cfgs.enable("sysctl_syspll");
+        }
+        _ => {}
+    }


This feels a little strange to me. Open to suggestions on how better to identify if SYSPLL is available.

We do have metadata for a clock tree from sysconfig, just haven't plumbed it up yet.

Is this approach reasonable for now, and just plan to improve it down the line?

For now this is fine.

i509VCB · 2026-01-25T19:03:41Z

embassy-mspm0/src/lib.rs

+    // TODO: should these be found via the PAC instead of hard-coded?
+    // From looking at the G series TRM, these addresses are constant,
+    // but it still feels wrong.
+    // Taken from table "Table 1-135. FACTORYREGION_TYPEG Registers"
+    // (constants identical to Table 1-116. FACTORYREGION_TYPEA Registers for PLL.)


Longer term I do want to expose the factory region in this crate in a factory module. Haven't gotten to it yet.

magmastonealex · 2026-01-25T19:07:03Z

CI fails due to:

error[E0432]: unresolved import `rand_core`
  --> /ci/code/embassy-mspm0/src/trng.rs:13:5
   |
13 | use rand_core::{TryCryptoRng, TryRngCore};
   |     ^^^^^^^^^ use of unresolved module or unlinked crate `rand_core`
   |
   = help: if you wanted to use a crate named `rand_core`, use `cargo add rand_core` to add it to your `Cargo.toml`

~~I think this has been the case since #5172 ?~~ No - it's because a bad rebase on my end dropped rand_core from Cargo.toml. Fixed now.

i509VCB · 2026-01-25T19:07:13Z

examples/mspm0g3107/README.md

+
+## Checklist before running examples
+
+The MSPM0G3107 does not have a Launchpad or official development board, so you likely need to modify examples to update pin numbers or peripherals to match the specific MCU or board you are using.


Might be worth mentioning G3507 will be quite similar to this.

I've updated this line to mention that the examples should also run there with minimal changes.

I decided to create a separate examples folder for this specific MCU since I don't have access to others to test against.

i509VCB · 2026-01-25T19:08:37Z

CI fails due to:

error[E0432]: unresolved import `rand_core`
  --> /ci/code/embassy-mspm0/src/trng.rs:13:5
   |
13 | use rand_core::{TryCryptoRng, TryRngCore};
   |     ^^^^^^^^^ use of unresolved module or unlinked crate `rand_core`
   |
   = help: if you wanted to use a crate named `rand_core`, use `cargo add rand_core` to add it to your `Cargo.toml`

I think this has been the case since #5172 ?

Weird, the pull request clearly adds that to Cargo.toml?

magmastonealex · 2026-01-25T19:10:01Z

Ugh, yeah. I accidentally deleted rand_core = "0.9" from Cargo.toml and didn't notice. Let me add that back in.

i509VCB · 2026-01-29T03:12:24Z

embassy-mspm0/src/can/mod.rs

+pub struct Config {
+    /// Input clock divider
+    pub clock_div: ClockDiv,
+
+    /// CAN timings to use for standard CAN. (CAN-FD support to come later.)
+    pub timing: CanTimings,
+
+    /// If remote frames should be accepted into the RX queue.
+    pub accept_remote_frames: bool,
+
+    /// If extended ID frames should be accepted into the RX queue.
+    pub accept_extended_ids: bool,
+}


I have a feeling that the code could calculate some of the timings for you to get a specific bitrate and back calculate from clock config. See the UART driver for an idea of this.

It certainly can! I have listed it as an excluded feature for now to get something minimal working.

The algorithm is a bit complex, which is why I left it out, but there are other implementations out there (even in embassy-stm32).

I can include it if you want - but my original intention was to follow up and add it in later since it’s another ~250 lines of code.

i509VCB · 2026-01-29T03:13:17Z

embassy-mspm0/src/can/mod.rs

+#[derive(Clone, Copy, PartialEq, Eq, Debug)]
+#[cfg_attr(feature = "defmt", derive(defmt::Format))]
+/// Config Error
+pub enum InitializationError {


Use ConfigError to match other drivers.

Good point, updated.

i509VCB · 2026-01-29T03:14:40Z

embassy-mspm0/src/can/mod.rs

+                return Err(BusError::BusOff);
+            }
+
+            cortex_m::asm::delay(100);


Required due to timing bugs in hardware?

Removed. Didn’t mean to leave this in. Thanks for catching it.

i509VCB · 2026-01-29T03:16:10Z

embassy-mspm0/src/can/mod.rs

+// I am really not sure that these are good abstractions for real applications.
+// They do not support "confirmable" mesage sending (i.e the docs specifically state that
+// transmit() only enqueues frames, there is no feedback mechanisim to confirm if/when a frame
+// was actually sent)
+// They also do not support monitoring the peripheral's status or recovering from bus-off.
+// I will implement them regardless to play nice with the overall ecosystem,
+// but similar to embassy-stm32, I'm going to offer a HAL-specific API which provides
+// more useful functionality, and add an async variant at some point.


I feel this is a question that could be an issue on the embedded_can crate. I am not 100% familar with CAN, but would confirmation be something that hardware reports or is that part of a "CAN stack".

It depends on the hardware as far as I know - the MCAN IP does support hardware reports of confirmed successful transmission, but I don’t think all IPs do. Some higher level protocols might include protocol-layer ACKs as well, since the CAN ACK just means some device received it correctly, not that the destination received it.

I don’t neccessarily see it as an issue within embedded_can - confirmable messages and asynchronous support are important to the specific applications that I have built, but general hardware support may not be there to expect every MCU to support them.

It’s more that our peripheral can do more, so I want to expose methods to make more use of what is there.

i509VCB · 2026-01-29T03:17:06Z

embassy-mspm0/src/can/mod.rs

+use crate::can::msgram::{McanMessageRAM, MessageRAMAccess};
+use crate::gpio::{AnyPin, PfType};
+use crate::mode::{Blocking, Mode};
+use crate::pac::canfd::{Canfd as Regs, vals as CanVals};


Usually we don't rename path elements. Leaving it as vals is fine.

Ooops - leftover from out of tree. Updated.

i509VCB · 2026-01-29T03:19:48Z