Grace 3.0 start-up code doesn't clear the LOCKLPM5 bit

The LOCKLPM5 bit is only set if LPMx.5 is entered intentionally. And if so, then upon restarting the device, special care needs to be taken to NOT initialize the device as usual after power-on, but instead preserve some configurations before clearing the bit. So GRACE shouldn’t and cannot decide when to clear it. It has to be done by the user after all is set-up, or the whole lock mechanism would be rendered useless.

Jens-Michael Gross said:

The LOCKLPM5 bit is only set if LPMx.5 is entered intentionally.

This is why I thought GRACE should have some (default) option to clear the LOCKLPM5 bit as otherwise the I/Os won;t be active after a reset or power-up.

If you create a non-GRACE example project in CCSv6 for a MSP430FR5969 the following code is inserted:

int main(void) {
    WDTCTL = WDTPW | WDTHOLD;               // Stop watchdog timer
    PM5CTL0 &= ~LOCKLPM5;                   // Disable the GPIO power-on default high-impedance mode
                                            // to activate previously configured port settings

Okay, the LOCKLPM5 bit is different in F5x and FR5x family then.
However, my explanation still applies: if LOCKLPM5 was set due to LMPx.5, the GRACE startup code must not clear it before the user has finished re-initializing all affected registers. GRACE cannot know whether this is required or not.  So how to decide when to do it automatically?

If done automatically during GRACE init, this means that the user must have done all additional initialization before the GRACE startup code is called. Which might be impossible due to the required chain of actions. This would mean that a GRACE project cannot use LPMx.5 at all.

I think you still can initialize GPIO after clearing LPM5 bit. So Grace can clear LPM5 in the generated code before users setup their own application.

Sure you can. The problem is: writes to config registers take effect the moment LOCKLPM5 is cleared. Depending on situation, you need to write to the registers before it is cleared (after a real LPMx.5 situation, so the hardware won’t switch to the defaults before you reconfigure it) or after (so you can see the effects of your configuration e.g. in a check loop. GRACE doesn’t know what you want to do, so it cannot decide when it is advised to clear the bit.

Nothing is worse than an automatism that automatically does the things wrong and cannot be disabled.

http://mooker.com/News-Outlets/Tale_Of_The_Incompetent_Arab_Airbus_340_Flight_Crew_Debunked.shtml

The story is claimed to be a fake (but that’s what I’d claim too if I were involved). Nevertheless, it shows how automatisms can lead to chaos and you can’t do anything.

Thanks for sharing story, Michael.

I understand what you are saying, so it is better to add option in the Grace to clear LOCKLPM5 bit. By default, LOCKLPM5 is cleared and user can manually uncheck the option during configuration.

Indeed, this would be optimal. (I don’t say ‘best’ because the user still needs to know that he has this option and might require to use it. But don’t think there is a ‘best’ way at all.)

Yang Lu said:

I understand what you are saying, so it is better to add option in the Grace to clear LOCKLPM5 bit. By default, LOCKLPM5 is cleared and user can manually uncheck the option during configuration.

1) With grace_3_00_01_48_en the Grace generated code didn't clear the LOCKLPM5 bit.

2) With Grace 3.0.1.59 the Grace generated code did clear the LOCKLPM5 bit, by a call to PMM_unlockLPM5 inside PinMux_graceInit

3) With Grace 3.0.2.64 the Grace generated code has reverted to not clearing the LOCKLPM5 bit.

Is there a reason for the change being made to make Grace clear the LOCKLPM5 bit, only for the change to be removed in a later version of Grace?

Chester Gillon said:

Is there a reason for the change being made to make Grace clear the LOCKLPM5 bit, only for the change to be removed in a later version of Grace?

The explanation is simple. Originally, the bit wasn’t reset, either intentionally, or unintentionally. Then someone detected that the bit isn’t reset and implemented it. And finally, it was found that always resetting the bit will completely counteract the purpose of the bit, which is there to be NOT reset in case of an LPMx.5 wakeup until all initialization is done. After all, always clearing it would be as if it wouldn’t exist. And it does exist for a reason.
So it was removed again.
I guess, a future version will make it configurable, so it is cleared by default (works for most projects9 but can be deactivated if required (in projects that use LPMx.5).