MSPM0G1505: MSPM0G1505 Intermittent FLASH_DED NMI / HardFault Resets Related to HFXTRSEL Setting

Hi Mark,

Your HFXTRSEL experiment is a significant clue. For a 4 MHz crystal, DL_SYSCTL_HFXT_RANGE_4_8_MHZ is the nominal datasheet setting. The MSPM0G1505 electrical characteristics specify HFXTRSEL=00 for 4–8 MHz and HFXTRSEL=01 for 8.01–16 MHz. Therefore, using the 8–16 MHz range with a 4 MHz crystal should be considered an errata workaround/diagnostic condition rather than the normal production configuration. The increase in current and change in measured frequency that you observed are also reasons I would not recommend simply adopting the 8–16 MHz setting as the final solution without further confirmation.

The current MSPM0G150x/G350x errata, Rev. H, still contains CLK_ERR_01. It states that when MCLK is sourced directly from a 4 MHz HFXT and HFXTRSEL=0, random HardFault or NMI behavior can occur with the debugger connected; the documented workaround is to select HFXTRSEL=1 or higher while debugging. Your observation is particularly interesting because you can make the failure appear with the nominal 4–8 MHz setting and disappear with the same workaround even when the debugger is disconnected.

Based on the currently published errata, I would not consider intermittent FLASH_DED/NMI operation expected in a standalone system simply because a 4 MHz crystal is configured with the correct 4–8 MHz range. The published scope of CLK_ERR_01 is specifically the debugger-connected case. I also do not see a documented mechanism stating that a valid HFXTRSEL=0 setting at 4 MHz should directly create a Flash ECC double-error event. Because your result reproduces the CLK_ERR_01 workaround outside its documented condition, I think this needs to be escalated internally rather than assuming the 8–16 MHz setting is the production fix.

There is another erratum I would test before changing hardware: CPU_ERR_03. It states that when entering a low-power mode with a pending flash prefetch, the prefetcher can capture incorrect data. After wakeup, the CPU can then execute incorrect instructions if the prefetch/cache has not been flushed. The documented workaround is to disable the prefetcher before __WFI()/__WFE(), perform the shutdown-memory access needed to ensure the prefetch disable has taken effect, enter the low-power mode, and then re-enable prefetch after wakeup. This is especially relevant because you have already correlated DEDERRADDR with locations around __WFI().

I would suggest the following next test sequence:

1. Return HFXTRSEL to the correct DL_SYSCTL_HFXT_RANGE_4_8_MHZ setting.
2. Apply the CPU_ERR_03 prefetch workaround around every __WFI()/__WFE() and rerun the same stress test.
3. In the NMI handler, capture DEDERRADDR, NMI source, CPUSS->CTL, HFXTRSEL, clock status, and MCLK source before returning from the NMI.
4. In the HardFault handler, capture the stacked PC and LR so we can determine whether the HardFault is occurring on the same flash fetch that generated the DED event.
5. Repeat with the debugger physically disconnected and with any automated reconnect/reset behavior disabled.

One other point when interpreting DEDERRADDR: FLASH_ERR_04 documents an incorrect address representation when the DED occurs outside Main Flash, and FLASH_ERR_05 allows a specific nonzero reset value in DEDERRADDR. If your captured addresses are genuinely within the Main Flash code region around __WFI(), those two errata would not explain the result.

You have already eliminated several of the more common causes—no runtime flash programming, no DMA reads from flash, correct flash wait states, and no evidence of stack/pointer corruption. Given that changing only HFXTRSEL reliably commands the failure in and out, I agree that the clock configuration is strongly correlated with the issue. I would therefore test the CPU_ERR_03 workaround first and, in parallel, escalate this as a potential extension or related manifestation of CLK_ERR_01 under standalone operation. I would not recommend using HFXTRSEL=8–16 MHz permanently with a 4 MHz crystal until that behavior is confirmed as an approved workaround for the non-debug case.

Thanks Brian for your in depth response.

I will work on getting CPU_ERR_03 tested. I have tried the disable and flush code around the __WFI() code earlier and still had failure, but I will run that formally to verify behavior with a controlled change and test. That way we can move forward with confidence or find out that it solves the issue.

As an aside, I have been extracting data by bit-banging addresses out on some pins, after trapping the interrupts, as our debugger has been unable to remain connected during runtime. 

During my failures I have seen no occurrence of FLASH_ERR_04.