[2252] High power consumption with ACLK on P2.0

I cannot say for sure for the 2252, but IIRC, clocks that are used cannot be deactivated and crystals used as source for an active clock are not deactivated too. On the 5438, ACLK will not be deactivated if an UART is sourced by it, even if idle. And if ACLK is active, the crystal stays active, even in LPM where it should be normally off.

So it is possible that in your case ACLK and crystal are still active. Anyway, 115µA might be an expected power consumption for LPM0 with SMCLK running on DCO with 1MHz.

Also, you might check the other port settings for P2.0 such as pullup active (creates excess current when output is pulled low by TA), drive strength, different P2OUT setting etc. There are lots of possible side-effects which might affect power consumption in LPMs

Also, check your devices errata sheet. Maybe it lists a device erratum regarding ACLK, LFXT and LPMs. This is an advice for every 'strang behaviour' situation, as teh device datasheet only describes what should be, while the errata sheet lists where and when it isn't.

Thanks for the advices.

In fact when I say "LPM3+ACLK",  the ACLK means that the clock is outputted on P2.0, I apologize me for my inaccurate english:(

So the only difference between "LPM3" and "LPM3+ACLK" in code is "bis.b #01,&P2SEL" before entering LPM3.

I checked the configuration of port 2 and it seems ok , every pin as 0V output, interrupt and pull down/up disabled, P2.7 and P2.6 as special function (cause LFXT1). It seems there is no information about this behavior in errata sheet:(

Edit: - Just forget this:) -

It still could be possible that teh device detects that ACLK is not used anywhere and shuts it off in the first case, but as soon as you assign it to an output port it is considered as 'required' and won't shut off anymore.

But even then, the power consumption is a bit high.

I don't knwo why the controller wouldn't like the two lines. But try swaping them. IIRC, PxOUT has a different meaning if the ports are set as inputs. And if the port is selected (PSEL) meanings change again. After all, without knowing your setup code, anything can be the reason.

Also, put a NOP behind the instruction entering the LPM. Anything else might cause the LPM not being entered correctly.

The ACLK signal is always used, and always from the LFXT1 crystal.

The problem is not ACLK nor LPM3 because measurement are ok (cf. post 1) and software works as intended. If I replaced the LMP3 enterring sequence with a forever nop loop, power consumption is 3mA (as expected).

The problem is when activating the ACLK signal on P2.0, special function of this port, the power consumption grows to ~120uA (2-3uA in normal operation without special function on P2.0)

I added the init code as .txt format in my profile (don't sure how it works but you should have access to it:p)

"The ACLK signal is always used" might be true from your point of view, but the processor might think otherwise. Depending on the processor (I never used one of the 2xxx series) the term 'used' might be resolved on less obvious conditions than one would think. So e.g. on the 5438, a clock is considered unused and will be deactivated even if assigned to an active UART, as long as this UART is idle and not currently receiving/sending a byte. It is then reactivated (considered 'used') when a start bit arrives. So it is possible that the processor will deactivate everything normally, but decides to not do it if you enable the ACLK output. It was just a guess anyway.

I looked over your code and on first glance there's nothing obviously wrong with it. There are some parts I don't understand ( such as the bic.b#3Fh,&P2SEL  line: P2SEL is already 0 after PUC, so clearing only the lower bits is a NOP, and if not, what about the upper ones?). And why do you initialize some things based on defines and some with hardcoded values? Better define everything in the header and just use MOV commands for all inits. But that has (I think) nothing to do with the problem. Keep in mind that if putting the processor into an LPM where the XTALs are disabled, they won't come up immediately when the system is reactivated, but behave as if you just did a POR (well actually you did from their point of view)

But the reason for the power consumption might be something totally different. My suggestion is to check the device errata sheet for some unwanted and unexpected side-effects. Perhaps this additional power consumption is already listed there. Due to lack of experience with your processor (and no datasheets at hand too), I can only make some general suggestions, which I did. Maybe someone else has run into the same problem an can shed some light on this.

That's bad. If you can't trust your tools...

I guess your tool shows 117µA where it should show 11.7 (which would be okay for the given application with active clock output).

Well, you're not alone. I had some projects too where with all tested conditions things were right, but then failed miserably when operated under real-word conditions. right now I have an interface PCB that converts the CMOS output of my demo boards UART to RS232 levels. When I got erraneous characters, I blamed the DCO timing or my code or whatever. But it turned out to be a loose wire between the test board and the PCB.

s**t happens.