MSPM0G1507: MCLK Switch and SYSOSC Sleep1 Behavior

Stuart Baker

Part Number: MSPM0G1507
Other Parts Discussed in Thread: LP-MSPM0G3507

Customer is trying to setup the device with the following configuration:

Start with MCLK=SYSOSC in 32MHz mode.
Transition MCLK to LFCLK (LFXT already started ~30 seconds earlier).
Set SYSOSC to 4MHz.
Goto Sleep 1 (with SYSOSC running at 4MHz).

Both the customer and myself have prototyped the impelemntation, using similar sequencing, but cannot get the desired result.

    DL_SYSCTL_switchMCLKfromSYSOSCtoLFCLK(false);
    DL_SYSCTL_setSYSOSCFreq(DL_SYSCTL_SYSOSC_FREQ_4M);
    __WFI();

When I run the above sequence, the result is the following problems:

The switch over from SYSOSC to LFCLK is taking ~700+ microseonds. That is way too long for the customer applicaiton, and I can't understand why it would need so much time. This is verified by GPIO toggle instrumentation.
The SYSOSC frequency is still 32MHz (verified by routing it to the CLKOUT pin).

I have tried various alternatives such as switching the SYSOSC to 4MHz before the MCLK switch over, and substituting DL_SYSCTL_switchMLKfromSYSOSCtoLFCKL() API for DL_SYSCTL_setPowerPolicyRUN1SLEEP1(). The result is always the same. If we look at where the bulk of the ~700 microseconds is being spent, it looks like it is being spent in the following loop:

while ((DL_SYSCTL_getClockStatus() & SYSCTL_CLKSTATUS_CURMCLKSEL_MASK) !=
           DL_SYSCTL_CLK_STATUS_MCLK_SOURCE_LFCLK) {
        ;
    }

Why does it take so long since the 32kHz crystal is already running (30 seconds prior)? Do we need to wait in this loop? What are the consequences if we don't wait in the loop?

Also, how to get the SYSOSC to be 4MHz after switching the MCLK away from it?

Thanks,

Stuart

3 months ago

0 Owen Li 3 months ago

TI__Genius 9511 points

Hi Stuart,

I assume that the customer and yourself have looked over the TRM, but can you confirm that these steps are followed and values are set:

Also ensure that MDIV is disabled before changing the SYSOSC frequency.

DL_SYSCTL_switchMCLKfromSYSOSCtoLFCLK(false); will set the SYSOSC frequency back to the base value:

Furthermore:

I'm curious as to how you are measuring the 700us delay? I need to look into this more with my team, but will get back you once I have more information.

Best,

Owen

0 Stuart Baker 3 months ago in reply to Owen Li

TI__Genius 10840 points

Owen,

Thank you for the initial response.

Customer doesn't use SYSPLL or HFCLK_IN. They may be using HFCLK (I can check), but I am not using or enabling HFCLK in my example where I reproduced the issue.
MCLK is sourced from SYSOSC.
I have tried setting SYSOSC to 32MHz or 4MHz. It doesn't seem to make any difference, except I noticed when setting at 4MHz, it moves to 32MHz before starting the switch over.
The DriverLib API is performing the switch request, and leaving SYSOSC enabled or not based on the passed in parameter. Customer is using "false" so that the SYSOSC stays enabled.

I am aware that this Sequence sets SYSOSC back to 32MHz:

DL_SYSCTL_switchMCLKfromSYSOSCtoLFCLK(false); will set the SYSOSC frequency back to the base value:

However, Customer needs SYSOSC to run at 4MHz following the clock switch over. Commanding it to switch back to 4MHz following the switch over does not seems to work. Is this not possible? I think that is a serious concern for the customer, due to the expected increase in power consumption.

I am measuring the ~700MHz by toggling a GPIO before and after the DL_SYSCTL_switchMCLKfromSYSOSCtoLFCLK() API call. Some of that time is likely a few cycles of overhead, especially following the switch over. It takes a few clocks to effect a change "at the pin". I've also seen up to ~800MHz on some runs of the test case. A single 32kHz clock is ~30us, so if it takes ~4 clocks or so to flip the pin, maybe we are seeing ~100us to ~200us from the GPIO overhead. Let's assume that its ~200us overhead to flip the pin after the clock switch, why is it still taking ~500us for the switch over to occur when the 32kHz crystal is already started ~30s prior?

Thanks,

Stuart

0 Owen Li 3 months ago in reply to Stuart Baker

TI__Genius 9511 points

Hi Stuart,

Changing SYSOSC to run at 4MHz is possible. However, it should not be changed after switching MCLK to be sourced from LFCLK (See the screenshot at the bottom of my previous reply).

With that in mind, this makes me want to believe that it is not possible to have SYSOSC run at 4MHz while MCLK is sourced from LFCLK.

As for the delay you observed, the design team gave a guts-feel number of maybe 200us that they would expect for the switch. A suggestion is to bring out the MCLK frequency out on the CLKOUT pin so that you can observe when the clock signal actually changes, rather than relying on SW clock cycle uncertainty. You could still utilize a GPIO signal to represent the "timestamp" before switching to LFCLK.

Best,

Owen

0 Stuart Baker 3 months ago in reply to Owen Li

TI__Genius 10840 points

Owen,

How can I bring MCLK out to the CLKOUT pin? It does not look like an option either in the TRM or in SysCfg.

Thanks,

Stuart

0 Owen Li 3 months ago in reply to Stuart Baker

TI__Genius 9511 points

Hi Stuart,

You are right, it is not possible to output MCLK from CLKOUT. I overlooked this in my previous reply.

I would suggest analyzing how many instructions and clock cycles it takes for the code executes between the GPIO toggling.

When I performed my own test, I observe the delay to only be ~280us. I tested this on a LP-MSPM0G3507 where I inserted a 30s delay upon the LFCLK starting up, then extracted the DL_SYSCTL_switchMCLKfromSYSOSCtoLFCLK() function where I set a GPIO output before MCLK is switched and clear the GPIO after the while loop.

Did the customer observe that the crystal was stable?

Best,

Owen

0 Stuart Baker 3 months ago in reply to Owen Li

TI__Genius 10840 points

Customer believes the 32kHz crystal is stable before they start the switch over. They start the 32kHz crystal 30 seconds before starting the switch over. I also did the same when reproducing the result.

The while loop at the end of the clock switch API is where we observe the largest component of the ~700us total. What is the consequence if we do not wait in this delay loop (extract the method and remove the while loop) and instead go directly to sleep (__WFI())?

Thanks,

Stuart

0 Owen Li 3 months ago in reply to Stuart Baker

TI__Genius 9511 points

Hi Stuart,

Since I cannot reproduce the issue, can you please share your code?

I am not sure we have an answer for consequences you can expect if you do not wait in the delay loop. In general when applications switch to LFCLK, you have to assume time does not matter. LFCLK is slow and therefore the application should only expect slow responses. It is always a good practice to wait for a clock switch to happen. If you need to switch to LFCLK, you want to wait till MCLK is really switched to LFCLK.

Best,

Owen

0 Stuart Baker 3 months ago in reply to Owen Li

TI__Genius 10840 points

Owen,

Please see attached, various lines are commented in/out based on my experimentation.

Regarding this statement:

If I understand correctly, customer wants to go to sleep immediately (__WFI()) following the clock switch. Can they do so without the waiting in the while loop at the end? Is there some other negative consequence to this we need to be concerned about. The peripheral they are using for timing (a hardware timer) is still being clocked from SYSOSC, though if I understand correctly, they wanted SYSOSC to be 4MHz.

Thanks,

Stuart

3386.gpio_toggle_output_LP_MSPM0G3507_nortos_ticlang.zip

0 Stuart Baker 3 months ago in reply to Stuart Baker

TI__Genius 10840 points

Owen,

I was also able to confirm that a GPIO toggle (set or clear) is one "STR" instruction in the disassembly. ...Assuming 1 CPU cycle for that instruction, the CPU execution time at 32kHz should be ~30.5us. As an additional test, I toggled the GPIO set/clear/set, looked at it on the logic analyzer. It is toggling 30.5us between edges.

I did notice however that when I remove the DL_SYSCTL_setSYSOSCFreq(DL_SYSCTL_SYSOSC_FREQ_4M), I'm now seeing about ~330us to ~520us (instrumented by GPIO) duration for the DL_SYSCTL_switchMCLKfromSYSOSCtoLFCLK(false) call. The request for SYSOSC=4M did not seem to be doing anything anyways, the SYSOSC was staying at 32MHz according to my CLOCKOUT instrumentation.

...I think the extra time I observed was coming from the SYSOSC=4M request. Are we confirmed that SYSOSC is fixed at 32MHz when MCLK source is 32kHz crystal?

Thanks,

Stuart

0 Owen Li 3 months ago in reply to Stuart Baker

TI__Genius 9511 points

Hi Stuart,

To answer your first reply, as I had said earlier, we do not know what you can expect in terms of consequences for not waiting. In general, it is best practice to wait for clock switching to complete. You may see undefined behavior if you do not wait in the while loop.

To answer your second reply, based on point 3 in the screenshot below, I do not believe SYSOSC can be anything other than base frequency if MCLK is sourced from LFCLK:

I uncommented line 48 in your code to set SYSOSC to 4MHz and I did observe the 4MHz clock to work. The API to switch MCLK to LFCLK then switches the SYSOSC frequency back to base (32 MHz) and I observed a delay of ~350-500us.

I went back and tested my code again and I actually see it vary from ~270-450us.

I will be reaching out further with my team to discuss this.

Best,

Owen

Arm-based microcontrollers

Arm-based microcontrollers forum

MSPM0G1507: MCLK Switch and SYSOSC Sleep1 Behavior