Forum - MCS Electronics

 

FAQFAQ SearchSearch RegisterRegister Log inLog in

Interrupts and power consumption
Goto page 1, 2  Next
 
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR
View previous topic :: View next topic  
Author Message
MadAl

Bascom Member



Joined: 26 Jul 2010
Posts: 35

blank.gif
PostPosted: Mon Dec 21, 2015 11:19 am    Post subject: Interrupts and power consumption Reply with quote

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 )
Back to top
View user's profile
Deanus

Bascom Member



Joined: 26 May 2006
Posts: 188
Location: Adelaide

australia.gif
PostPosted: Tue Dec 22, 2015 7:38 am    Post subject: Reply with quote

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
Back to top
View user's profile
MadAl

Bascom Member



Joined: 26 Jul 2010
Posts: 35

blank.gif
PostPosted: Tue Dec 22, 2015 7:57 am    Post subject: Reply with quote

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.
Back to top
View user's profile
MadAl

Bascom Member



Joined: 26 Jul 2010
Posts: 35

blank.gif
PostPosted: Thu Dec 24, 2015 1:18 pm    Post subject: Reply with quote

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:

Code:
Config Portd.5 = Output                                    
Csalti Alias Portd.5
'------------------------------------------------------------------------------
Config Porta.1 = Output                                    
Cspitot Alias Porta.1
'------------------------------------------------------------------------------
Config Portc.1 = Output                                    
Csaccsel Alias Portc.1
'------------------------------------------------------------------------------
Config Portd.4 = Output                                    
Csflash Alias Portd.4
'------------------------------------------------------------------------------
Rfm26_nsel Alias Portc.4                                  
Config Rfm26_nsel = Output

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

Do
NOP
Loop


The above code gives 34 mA power consumption and 4 of the defined ports are physically at low level (although set to 1).
Next experiment: toggling the ports in a loop:

Code:
Do_
    Rfm26_shut_dn = 1
    Power_sensors = 1
    Csalti = 1
    Cspitot = 1
    Csaccsel = 1
    Csflash = 1
    Rfm26_nsel = 1

    waitms 1000

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

    waitms 1000
Loop


This gives 11 mA power consumption (OK) and the voltage on the pins respond to the toggling
The next examples also gave an OK 11 mA where the pins are not toggled but assigned in a loop nevertheless:

Code:
Do_
    Rfm26_shut_dn = 1
    Power_sensors = 1
    Csalti = 1
    Cspitot = 1
    Csaccsel = 1
    Csflash = 1
    Rfm26_nsel =  1
    waitms 1000
Loop


or

Code:
Do_
    Rfm26_shut_dn = 0
    Power_sensors = 0
    Csalti = 0
    Cspitot = 0
    Csaccsel = 0
    Csflash = 0
    Rfm26_nsel =  0
    waitms 1000
Loop


It would appear the interrupts are part of the game here, as if I do this, the problem disappears:

Code:
Disable interrupts
Rfm26_shut_dn = 1
    Power_sensors = 1
    Csalti = 1
    Cspitot = 1
    Csaccsel = 1
    Csflash = 1
    Rfm26_nsel = 1
Do
NOP
Loop


However if I do this, the problem is back, although the interrupts are disabled:

Code:
Rfm26_shut_dn = 1
    Power_sensors = 1
    Csalti = 1
    Cspitot = 1
    Csaccsel = 1
    Csflash = 1
    Rfm26_nsel = 1
Disable interrupts
Do
NOP
Loop
Back to top
View user's profile
Deanus

Bascom Member



Joined: 26 May 2006
Posts: 188
Location: Adelaide

australia.gif
PostPosted: Fri Dec 25, 2015 1:13 am    Post subject: Reply with quote

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
Back to top
View user's profile
MadAl

Bascom Member



Joined: 26 Jul 2010
Posts: 35

blank.gif
PostPosted: Sat Dec 26, 2015 9:44 am    Post subject: Reply with quote

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.
Back to top
View user's profile
Deanus

Bascom Member



Joined: 26 May 2006
Posts: 188
Location: Adelaide

australia.gif
PostPosted: Sat Dec 26, 2015 11:06 am    Post subject: Reply with quote

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
Back to top
View user's profile
MadAl

Bascom Member



Joined: 26 Jul 2010
Posts: 35

blank.gif
PostPosted: Sat Dec 26, 2015 11:22 am    Post subject: Reply with quote

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.....
Back to top
View user's profile
MadAl

Bascom Member



Joined: 26 Jul 2010
Posts: 35

blank.gif
PostPosted: Sat Dec 26, 2015 9:31 pm    Post subject: Reply with quote

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.
Back to top
View user's profile
Evert :-)

Bascom Expert



Joined: 18 Feb 2005
Posts: 2113

netherlands.gif
PostPosted: Sat Dec 26, 2015 10:30 pm    Post subject: Reply with quote

MadAl wrote:

Code:
Config Portd.5 = Output                                    
Csalti Alias Portd.5
'------------------------------------------------------------------------------
Config Porta.1 = Output                                    
Cspitot Alias Porta.1
'------------------------------------------------------------------------------
Config Portc.1 = Output                                    
Csaccsel Alias Portc.1
'------------------------------------------------------------------------------
Config Portd.4 = Output                                    
Csflash Alias Portd.4
'------------------------------------------------------------------------------
Rfm26_nsel Alias Portc.4                                  
Config Rfm26_nsel = Output

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

Do
NOP
Loop




Not enough code to test for me, can you give your complete test code?

What about the bootloader? Does it set pins/ports/irq in a state your not aware of?
Do a full chip erase and only flash your test program to be sure the bootloader doesn't do thinks we don't want.

What devices are connected to the spi bus, can your give the type numbers.
Some spi devices can also be used as i2c devices, choosing between the i2c and spi mode is done sometimes by the CE pin (like the adxl345) ?? This can give strange behavior on a spi bus with multiply devices.

Schematic would also be handy.

Have fun,
Evert

_________________
www.evertdekker.com Bascom code vault
Back to top
View user's profile Visit poster's website
MadAl

Bascom Member



Joined: 26 Jul 2010
Posts: 35

blank.gif
PostPosted: Sun Dec 27, 2015 9:27 pm    Post subject: Reply with quote

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!)
Back to top
View user's profile
MadAl

Bascom Member



Joined: 26 Jul 2010
Posts: 35

blank.gif
PostPosted: Sun Dec 27, 2015 9:29 pm    Post subject: Reply with quote

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.


Last edited by MadAl on Sun Dec 27, 2015 9:34 pm; edited 1 time in total
Back to top
View user's profile
MadAl

Bascom Member



Joined: 26 Jul 2010
Posts: 35

blank.gif
PostPosted: Sun Dec 27, 2015 9:34 pm    Post subject: Reply with quote

Here the schematics (part of it). The Atxmega and the SPI devices.
Back to top
View user's profile
MadAl

Bascom Member



Joined: 26 Jul 2010
Posts: 35

blank.gif
PostPosted: Fri Jan 01, 2016 8:50 pm    Post subject: Reply with quote

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.
Back to top
View user's profile
Deanus

Bascom Member



Joined: 26 May 2006
Posts: 188
Location: Adelaide

australia.gif
PostPosted: Sat Jan 02, 2016 9:40 am    Post subject: Reply with quote

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
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum