mspm0: read_reset_cause()

[doxxx]

This adds a read_reset_cause function that returns an enum value derived from the SYSCTL.RSTCAUSE register.

Based on the work by @charlesbmi in #4732.

Example usage code tested on-device:

match embassy_mspm0::read_reset_cause() {
    Ok(cause) => {
        use embassy_mspm0::ResetCause::*;
        let desc = match cause {
            NoReset => "No reset since last read.",
            PorHwFailure => "POR- violation, SHUTDNSTOREx or PMU trim parity fault.",
            PorExternalNrst => "NRST triggered POR (>1s hold).",
            PorSwTriggered => "Software triggered POR.",
            BorSupplyFailure => "BOR0- violation.",
            BorWakeFromShutdown => "SHUTDOWN mode exit.",
            BootrstNonPmuParityFault => "Non-PMU trim parity fault.",
            BootrstClockFault => "Fatal clock failure.",
            BootrstSwTriggered => "Software triggered BOOTRST.",
            BootrstExternalNrst => "NRST triggered BOOTRST (<1s hold).",
            BootWwdt0Violation => "WWDT0 violation.",
            SysrstBslExit => "BSL exit.",
            SysrstBslEntry => "BSL entry.",
            SysrstWwdt1Violation => "WWDT1 violation.",
            SysrstFlashEccError => "Flash uncorrectable ECC error.",
            SysrstCpuLockupViolation => "CPULOCK violation.",
            SysrstDebugTriggered => "Debug triggered SYSRST.",
            SysrstSwTriggered => "Software triggered SYSRST.",
            CpurstDebugTriggered => "Debug triggered CPURST.",
            CpurstSwTriggered => "Software triggered CPURST.",
        };
        uart_log!(logger, 256, "Reset cause: {}", desc);
    },
    Err(code) => {
        uart_log!(logger, 256, "Reset cause: Unknown ({})", code);
    }
}

[doxxx]

I don't understand those ci/build failures. This builds just fine locally.

[doxxx]

Ah, I see the problem. For some MSPM0 chips the WWDT0 reset cause is a different level, so the generated PAC enum is named differently: BOOTWWDT0 vs SYSWWDT0.

[felipebalbi]

Ah, I see the problem. For some MSPM0 chips the WWDT0 reset cause is a different level, so the generated PAC enum is named differently: BOOTWWDT0 vs SYSWWDT0.

Maybe better to patch the PAC in that case?

[doxxx]

There's other funny stuff going on with the MSPM0L13xx PAC -- it has WWDT0 and WWDT1 reset causes but there's only one WWDT0 defined for e.g MSPM0L1306... And some of the PAC reset cause values don't line up with the MSPM0 tech reference either.

I'll investigate some more.

[doxxx]

I couldn't think of a better way to do this. Even if I fixed the reset cause Id enum in the PAC, it still would have a different set of values for the G-series, which would make for a horrific cfg condition to get it right. I thought it would be simpler to hard-code the values according to the tech reference.

[i509VCB]

I couldn't think of a better way to do this. Even if I fixed the reset cause Id enum in the PAC, it still would have a different set of values for the G-series, which would make for a horrific cfg condition to get it right. I thought it would be simpler to hard-code the values according to the tech reference.

In this case if there are enough differences I would just define 2 enums and pick based on chip family with cfg.

[doxxx]

In this case if there are enough differences I would just define 2 enums and pick based on chip family with cfg.

It's one extra enum variant for G-series chips. Everything else is the same as far as I can tell. I can use cfg to make that one enum variant only preset for G series.

Are you okay with using the hard-coded values instead of the PAC enum values?

[i509VCB]

In this case if there are enough differences I would just define 2 enums and pick based on chip family with cfg.

It's one extra enum variant for G-series chips. Everything else is the same as far as I can tell. I can use cfg to make that one enum variant only preset for G series.

Are you okay with using the hard-coded values instead of the PAC enum values?

Something like

PorHwFailure = pac::ResetCause::PorHwFailure

is fine for enum definitions. But I'm not sure we want to make it repr(u8)

[doxxx]

In this case if there are enough differences I would just define 2 enums and pick based on chip family with cfg.

It's one extra enum variant for G-series chips. Everything else is the same as far as I can tell. I can use cfg to make that one enum variant only preset for G series.
Are you okay with using the hard-coded values instead of the PAC enum values?

Something like

PorHwFailure = pac::ResetCause::PorHwFailure

is fine for enum definitions. But I'm not sure we want to make it repr(u8)

Alternatively, we don't define values for ResetCause and just let the compiler generate values. It doesn't look like other enums maintain the underlying register value.

[i509VCB]

Alternatively, we don't define values for ResetCause and just let the compiler generate values. It doesn't look like other enums maintain the underlying register value.

That's fine and probably preferable (we don't guarantee ABI stability of values)

[doxxx]

Spurious job failure?

[i509VCB]

Spurious job failure?

C1104 failed to build. Probably that missing Id field you mentioned?

[doxxx]

Spurious job failure?

C1104 failed to build. Probably that missing Id field you mentioned?

Ah crap, yes. I need to figure out how to do a build against every variant to catch that.

[doxxx]

This depends on mspm0-rs/mspm0-data#18 to add the missing PAC enum for the C-series but will still need further fixes since there are subtle differences in the PAC enum between series.