Interrupts and power consumption

MadAl · Joined: 26 Jul 2010 Posts: 48

I have a current consumption issue on my ATXMEGA256A3BU. It draws over 30 mA in my main program but the same hardware consumes 10 mA in a test program.
I went through the program lines, measuring the current after each line, and after the following line, the current jumps from 10 to 30 mA:

Config Priority = Static , Vector = Application , Lo = Enabled , Med = Enabled , Hi = Enabled

When I remark this line and remove the lo/med/hi from the IRQ's, the current does not jump to 30 mA.

Who has any idea where I should search which would explain this current jump?

(BASCOM-AVR version : 2.0.7.8 )

Deanus · Joined: 26 May 2006 Posts: 188 Location: Adelaide

Hi MadAl,

It's hard to say what would be causing your problem without knowing the circuit you've connected and seeing your program.

When you say 10-30mA is that just the processor or your whole circuit?

Going by the data sheet(link below), the absolute maximum of the processor is 15mA normally 10mA
with a 32MHz crystal.

http://www.atmel.com/images/atmel-8362-8-and-16bit-avr-microcontroller-atxmega256a3bu_datasheet.pdf

Maybe you should look at the consumptions of the items driven by the processor and what is turned on in the interrupts.

Dean

MadAl · Joined: 26 Jul 2010 Posts: 48

Thanks for your reply. It so appears that the problem with the single program line I referred to in my question, is linked to something else (I have a hunch some externally connected SPI devices).
Possibly (and very likely) this single line triggers some port states to change (something I will measure using a DMM) which will then either drive or sink current from the peripherals. I discovered this as after putting the ATxmega to sleep using an external 32.768 kHz crystal (using the RTC) the current was still up at 30 mA, so it definitely must be periphery related. I will continue my quest by searching in the SPI maze. Time consuming for sure but hopefully rewarding in the end.

MadAl · Joined: 26 Jul 2010 Posts: 48

I can not make a stripped down version of my program as the problem does not occur then. In summary I define a couple of ports for chip select of SPI devices.
Then I set these pins high to deselect all lines and the current jumps to 34 mA (11 mA is normal). First I thought the SPI devices were taking the excessive current, but closer inspection of the ports using a DMM gave an interesting result.
I measured the ports and discovered that they were all LOW except for one (despite being programmed to high).
So I did a test: toggling these pins at a 1 sec interval, and now the voltages on these pins go high and low and (hold your seat), the current dropped to 11 mA.
It gets even weirder: if I do a 'do-loop' and keep the pins set in the loop (no toggling), current drain is also 11 mA (OK).

So in summary:
setting 5 pins ‘high’ and then halting the program, some pins are not high but low and current is 34 mA
setting the same pins high in a do-loop, the voltages on these pins are high and current drops to 11 mA

It appears I have to rattle and shake these pins first before they respond :-O

First a short code summary of where the issue starts occurring:

Deanus · Joined: 26 May 2006 Posts: 188 Location: Adelaide

Hi MadAl,
Sounds like something that is attached to one or more of those ports is feeding INTO the micro.

For example are you using ISP to program your micro, if this is the case, Portd.5 in your list is "MOSI" which is the programmer, this could be left in a a low state after programming the chip, and your program is trying to take it high. Although, MOSI is an input to the programmer.

Have a look at the above link datasheet pages 57,58,59 and see what else is connected to those ports that you use, and, does your program use any of those items that might conflict if an interrupt is used.

Dean

MadAl · Joined: 26 Jul 2010 Posts: 48

Hi Deanus,

thanks for the input. ISP is used only once to program a bootloader. For this D6 and D7 are used. The bootloader pin is E5. D6, D7 and E5 are exclusively reserved for this in the hardware and no other peripherals are connected to these pins.
But if I program pins to a 'high' state, why would they be low and consequently sink current (which they apparently do?).
And why, if I make the pins in the above list subsequently high and low in a do-loop, the voltage on the CS pins are correct and the current remains low (both in high and low states)? This is all very inexplicable to me.
As to the pages you refer to, I presume they are of the ATXmega data sheet?

I did a short test by making all the pins in the CS list INPUT. As expected, the current dropped back to 11 mA. So when pulled high the ports are sourcing current into the SPI devices and when pulled low they are sinking current from the SPI devices (?) Fwiw, all the SPI devices appear to be working normally as I can communicate with them over SPI. But the funny thing is, when making all the CS ports output, the current is 30 mA, but if I make only one CS port output and the rest input, the current is still 30 mA. Defining subsequent ports as output still gives me 30 mA, so it is not like the SPI devices are sinking or sourcing current as that would mean a cascading current consumption.

thanks again and have a nice X-mas day.

Deanus · Joined: 26 May 2006 Posts: 188 Location: Adelaide

Hi MadAl,

Yea, I was thinkng about the toggling thing while I was writing the last reply. This is a bit of a weird one.

What is axctually connected to these pins ?

If it was me, I would be cutting tracks by now to isolate an offending pin and see if the low is comming from the attached circuit or the micro.
But that's just me, bit rough.
You set to output, and the micro can't have a pin in both states at the same time so that only leaves whatever is connected to the pins
Is it ALL the described pins or only some of them ?

Set one pin high at a time to see if iit's one or more drawing current.

Config Portd.4 = Output
Csflash Alias Portd.4
'------------------------------------------------------------------------------
Rfm26_nsel Alias Portc.4
Config Rfm26_nsel = Output

Rfm26_shut_dn = 1
Power_sensors = 0
Csalti = 0
Cspitot = 0
Csaccsel = 0
Csflash = 0
Rfm26_nsel = 0

Do
NOP
Loop

Compile, test current draw, change the "one" to next pin & repeat

Dean

MadAl · Joined: 26 Jul 2010 Posts: 48

Dean,
I do not think it is a sink or source issue. I have a very simple and short test program with the very same pin definition and it is working just fine!
What is connected to these pins are the channel select (CS) pins of a few SPI devices (pressure sensors, RAM, accelerometer, all low power stuff)
These lines are part of a big program (3k lines). Mind you, I have been testing this program in spring this year for current consumption, and all was working fine. Now with the program nearly finished I tested the current consumption again and things were not OK. So I went back to the old program which I used in spring: also too much current! Could it be this is induced by a Bascom upgrade? One starts wondering....

All these pins trigger this behaviour, and no matter if they are high, low, all or just a few high or low (or any mix), current remains 30 mA. Only when they are ALL defined as input, current drops to normal levels. One, a few or all to output and current jumps to 30 mA for all configurations.

Another weird one: if they are all defined as output and I disable interrupts before the ports are defined, current is normal. If interrupts are disabled after the ports are defined, current is abnormal. All in all, I pretty much lost it.....

MadAl · Joined: 26 Jul 2010 Posts: 48

Just wrote a program to test all the SPI devices. All CS pins are set to high: current is normal and SPI devices behave normally.
So it is definitely not the pins sinking or sourcing current. Something else is acting up.

Evert :-) · Joined: 18 Feb 2005 Posts: 2156

MadAl · Joined: 26 Jul 2010 Posts: 48

Here is the simple test program, which defines the same CS pins and works like a charm (current is normal and SPI devices work). In my next post I will attach the program in which these ports do not work using the same code. I will also attach the schematics.

In the following codes, current goes down to normal in the 'big' program:

If I position the lines which define the state of the CS pins (all set) inside a do loop
If I toggle the CS ports high-low-high etc. within a do-loop at a 1 sec pace
If I toggle the CS ports in a for-next loop (after the loop current jumps back to > 30 mA)
If I disable the interrupts before the definition of the CS pins (disabling interrupts after defining the CS pins gives > 30 mA again!)

MadAl · Joined: 26 Jul 2010 Posts: 48

Here the 'big' program where current and CS ports go off track. The piece of code can be found in the quadant_config.inc file.
Next post: the schematics.

MadAl · Joined: 26 Jul 2010 Posts: 48

Here the schematics (part of it). The Atxmega and the SPI devices.

MadAl · Joined: 26 Jul 2010 Posts: 48

I got somewhat closer to the problem and have built the entire program from the ground up. I started with the SPI definitions and current consumption was normal until the program grew in size close to the original program. Then the problem started whenever I added code (no matter what type of code) the current jumped to 30 mA. As an example, a simple statement like waitms 200 triggered the 30 mA current consumption. Removing only this command dropped the current back to 11 mA. So it looks something inside the controller under Bascom command is acting up and we can rule out external periphery devices.

Deanus · Joined: 26 May 2006 Posts: 188 Location: Adelaide

Hi MadAl,

Lost for answers on this one, the micro alone shouldn't behave like that.

Could be a stuffed micro, but I would still be inclined to rem out certain routine calls.

Put your extra code like the

waitmS 200 so that current goes to 30mA, in fact put a few of them to create a bigger program as you suggest.

disable certain calls one at a time like SPI to see if it goes back to 11mA

This would be the only way to track down the problem

Even though you say (for example) that the SPI is working, this is not saying that some thing else is not interfering with you chip selects or something else is accessing a periperal by accident somewhere else in your program after you add more code.

$Stack
$Frame etc big enough ?

Adding extra program might be overwritting something else ?

Disable the interrupt with the extra code on place ( which causes the 30mA)

Add known harmless code that does nothing with the periperals (like your delay) to keep the program large, and disable something that does use the periperals.
I has to be something causing the larger current drain, and I really doubt that it's the micro.

Dean