Switching MCLK source from DCO to ACLK and back

Jean-Michel Rubillon said:

Hi Folks,

Here's what I'm trying to achieve:

Have my MSP430F2491 start-up with the 16MHZ DCO as the source for MCLK and SMCLK.
Do all the system initialisations and some work. Once there is no more work to be done switch the MCLK source to ACLK and enter LPM3

Every timer tick, check if one of the software timers has lapsed. If so then return the MCLK source to be the 16MHz DCO and return to active mode, otherwise just return to LPM3.

So far, what I have managed to do is:

Start-up in 16MHz DCO. Set-up ACLK be the source for my timer tick (so I know ACLK is always running).

I successfully enter LPM3 and process the interrupt as it happens.

However, when I monitor the MCLK on an output pin I never see it switch to th 32.768kHz ACLK. It's at the 16MHz when the timer tick happens and stopped when in LPM3.

Because the DCO is still running my current consumption is still in the 2mA range when Ideally it should be in the 200-300uA range.

Has anyone got some working sample code that does something like what I'm trying to do?

 

That's the right behavior (and you cannot source MCLK from ACLK, you could use same source for MCLK and ACLK ). What makes you think that the DCO is still running? if you are using the correct settings DCO is automatically started/stopped at interrupt start/end.

Regards,

Peppe

peppe is right- Yu cannot 'switch the MCLK to ACLK'. MCLK, SMCLK and ACLK are parallel clock distribution channels. Tehy can have the same or different sources.

However, swithcing MCLK source from DCO to something else is not necessary if you enter LPM. If LPM1 (or higher) is entered, the DCO is automatically switched off if nobody nees it. Eitehr some hardwar eis still requiring the DCO, or it is off.

However, when DCO needs to be switched on again due to an interrupt, it takes some µs to comeup again. So if you have too many interrupts. the DCO won't be off for long.

On 16MHz, the running MSP will consume >9mA for CPU/DCO. The given low µA for LPM3 are for continuously sleeping MSP with NO interrupts. As sonn as you have intrrupts, your current consumption rises. How much it rises, depends on your code, the interrutp source, and other things.

Also, teh stated current consumption does not include external currents (caused by I/O pins, pullups, whatever). If the MSP drives an LED, no LPM will drop th current below the LED current :)

Worse: if you indeed switch MCLK to the ACLK source (32kHz) befoer entering LPM, this means that from this moment on, MCLK will be 32kHz. Including the ISR entry sequence until teh DCO is enabled again and MCLK is switched back. So much time has been wasted with the CPU active before it begins actually doing something useful in the ISR. It's possible that when you reach this point, the next interrupt is already scheduled adn the MSP will never really reach LPM.

Ok, Thanks, I should have said XT1 instead of ACLK.

Jens-Michael you're saying that the DCO is automatically switched off if nobody needs it. Does this mean that if my SMCLK is derived from the DCO the DCO will not shut down when I want to enter LPM3? Do I need to shutdown all the peripherals as well? That doesn't seem right. Unless all I need to do is disable the SMCLK?

Maybe I don't need to use the 32kHz XT1 as my MCLK before switching to LPM3.

All the pins on the processor are either connected to other ICs or not connected at all but configured as inputs with internal pull-ups. So I should be able to reach the sub mA currents advertised in the datasheet.

I'll take another look at my code to see where I've messed-up.

Jean-Michel Rubillon said:

All the pins on the processor are either connected to other ICs or not connected at all but configured as inputs with internal pull-ups. So I should be able to reach the sub mA currents advertised in the datasheet.

If I remember correctly the datasheet suggests to switch unconnected pins to output direction and drive them low (or high, don't remember exactly). That way you can save the current wasted in the pull-up resistors.

Jean-Michel Rubillon said:

Does this mean that if my SMCLK is derived from the DCO the DCO will not shut down when I want to enter LPM3?

Only if the SMCLK is actively needed by a module (say sending something using the UART derived from SMCLK) - if not the SMCLK is also shut down when entering LPM3.

Maybe you can give us a hint which modules you are using, that makes it easier to guess which module might be eating your milliamps.

Bernhard Weller said:

If I remember correctly the datasheet suggests to switch unconnected pins to output direction and drive them low (or high, don't remember exactly). That way you can save the current wasted in the pull-up resistors.

Good thinking there. I shall try that first thing Monday morning. Hopefully that will make all the difference as even when I don't have anything going on on the peripherals (one SPI port and one I2C) and a couple of inetrrupt pins on P1, the current being drawn even at 1.1MHz is in the 2mA range.

Bernhard Weller said:

Only if the SMCLK is actively needed by a module (say sending something using the UART derived from SMCLK) - if not the SMCLK is also shut down when entering LPM3.

Right. If SMCLK isn't unconditionally requested, it will be shut off in LPM3, and so will DCO.
IIRC, there is a bug in USCI module that will unconditionally request SMCLK or ACLK when active, even if nothing is currently received.
In theory, the clock can be off until a start bit is detected.
However, the time required to bring DCO on again for the clock, and perhaps the overshooting of the starting DCO, will cause the USCI to fail on receiving the first byte properly. So I guess this 'bug' was intentional to have the USCI receive workign in LPMs. If you don't want to receive during LPM, shut the USCI off before entering LPM3/4 for SMCLK/ACLK being allowed to shut off.

Bernhard Weller said:

If I remember correctly the datasheet suggests to switch unconnected pins to output direction and drive them low (or high, don't remember exactly)

Jens-Michael Gross said:

If I remember correctly the datasheet suggests to switch unconnected pins to output direction and drive them low (or high, don't remember exactly)

Low. Driving an unconnected pin low won't consume any current. Driving it high could cause some leakage currents.
Well, driving low might do so too, but then it is an external leakage and doesn't count for MSP current :)[/quote]

Well this one made a small impact: ~300uA which is good.

Jens-Michael Gross said:

Only if the SMCLK is actively needed by a module (say sending something using the UART derived from SMCLK) - if not the SMCLK is also shut down when entering LPM3.

Right. If SMCLK isn't unconditionally requested, it will be shut off in LPM3, and so will DCO.
IIRC, there is a bug in USCI module that will unconditionally request SMCLK or ACLK when active, even if nothing is currently received.
In theory, the clock can be off until a start bit is detected.
However, the time required to bring DCO on again for the clock, and perhaps the overshooting of the starting DCO, will cause the USCI to fail on receiving the first byte properly. So I guess this 'bug' was intentional to have the USCI receive workign in LPMs. If you don't want to receive during LPM, shut the USCI off before entering LPM3/4 for SMCLK/ACLK being allowed to shut off.

[/quote]

That's the tricky bit now. I'm using USCIA0 in SPI master mode and USCIB1 in I2C master mode. I've tried putting both modules' state machines in reset (UCxxCTL1 = UCSWRST;) but that doesn't seem to make any difference to the current draw.

Do I have to put all the USCI registers to their reset values or is there a simpler way (that doesn't eat-up instruction cycles for the sake of it)?

Thanks for all the feed back so far. Much appreciated.

 

Jean-Michel Rubillon said:

I've tried putting both modules' state machines in reset (UCxxCTL1 = UCSWRST;) but that doesn't seem to make any difference to the current draw.

But there might be others still requesting a clock. WDT? Timers?

Also, having the debugger attached does influence the LPMs. Some LPM features are not active when teh debugger is applied. Not to mention the JTAG interface which is active then too and consume ssoem power.

If the debugger is attached almost any current reading is worthless as there are quite some currents flowing in and out of the debugger - I had readings go up by 1mA one time as I attached the debugger which was about 3 times as much as my system used in the end.