28X1 chip to chip power consumption variations

[tchapin]

Hi,

First I wanted to express my gratitude to the picaxe group. I've been working with these chips for ~2 years and searching the forum has saved me from a lot of headaches and user blunders.

OK, here's the problem. I use the 28X1 with the 28X project board (AXE 020) to control a battery powered field instrument. The 28X1 is powered by 3 AAs while a separate battery drives some solenoids. These instruments are deployed for up to a year in freezing conditions and are in low power sleep for 99% of the time so ultra low power sleep is essential.

I run a simple test program just to check the power draw during sleep for each 28X1 chip. Chips are inserted into the same 28X project board which is pre-assembled with inputs tied to ground . After program is downloaded and serial comms cable is removed.

(http://www.rev-ed.co.uk/docs/axe020.pdf)

' 28X1 low power test program
' fresh AA batteries
' 28X project board#2, no modifications or added circuits to project board
' no solenoids connected, darlington driver in socket but not used.
' program editor 5.2.5
' runs at 4MHz which is resonator on 28X project board

Main:
disablebod ' turns off brownout detect, lowest power sleep
sleep 3
enablebod ' turns on BOD, bumps current draw to ~200 uA
sleep 3

goto Main

The first 28X1 chips I received were great, I had sleep currents of 1.6-1.9 uA The most recent chips I received all have much higher current draw during sleep. These results use the same 28X1 project board so the only difference is the 28X1 chip.

chips#1-3: 1.6-1.9 uA, firmware= A.2, processor batch# 07012QC
chips#4: 103 uA, firmware= A.2, processor batch# 07012QC
chips#5-10: 125-129 uA, firmware= A.3, processor batch# 08103MD

At first I thought it was a firmware issue since the older chips were A.2 but I have an A.2 chip that draws 103 uA during sleep. Then I thought it was the processor batch# but I have a 07012QC chip that draws over 100 uA. All the newer chips have the A.3 firmware and batch# 08103MD and higher current draw of around 125 uA. I also have some new 28X2 chips, both 5V and 3.3V and they draw <3 uA with the same test procedures (slightly different program).

Anyone encounter this before? Have any ideas why the more recent 28X1 chips have higher power draw and any potential fixes? 125 uA may not sound like a lot of power draw for some people but it’s lethal for my application. Adding more battery capacity is not a viable option.

Thanks very much,
Thomas

 

[hippy]

Welcome to the PICAXE forum.

Low-power operation isn't my speciality and I cannot say what has changed to increase the consumption.

If 28X2's draw low enough currents the pragmatic decision may be to use 28X2 chips instead of 28X1.

 

[BeanieBots]

Interesting.
I had suspected something similar to your observations but had dismissed it as it was not important to me at the time.
If I get time, I'll do some tests.

The current depends a lot on which internal 'modules' have been made active so your code will have a large impact on current even without any external loads.

 

[Dippy]

That is interesting.

Just to take BB's comments a stage further, I would be tempted to do the following:
1. Get the Microchip PIC data sheet and look at the claimed figures for the consumption of the DC Caharacteristics in table 17.3.
2. Peek (if possible) the appropriate registers to see if the default status explains the current consumption during 'sleep'.
2. Poke the appropriate registers to switch the peripheral off to see if your results change.

The register addresses are shown in the Data Sheet - requires a little hunting around.

(I seem vaguely to remember a while back the enable/disable bod was back to front).

 

[tchapin]

Compared all the register values between the 'good' 28X1 (1.8 uA) and the 'bad' 28X1 (128uA). All the register values are the same except a few that you'd expect to be different (i.e TMR0). None of the peripherals such as ADC are 'ON'

 

[Dippy]

Blimey.
So, have you measured the current with all peripherals and oscialltors off?

i.e. BOR, CCP , CVref , ADC , Osc all switched OFF.

And PIC gone to Sleep with no odd I/O settings?

You may also try switching off the WDT, - BUT I assume PICAXE firmware uses the WDT interrupt to pop out of Sleep, so be aware of that.

If you are certain that its not a circuit issue or your code switching something AND you still read over 100 microAmps then I suggest you contact Microchip Technical Support directly.

And you are definitely within the recommended voltage supply range?

 

[hippy]

In Post #14 of the linked thread, one of the secrets to low-power 28X2 operation was found to be pulling the external resonator inputs down to 0V. That may be worth trying with the 28X1.

http://www.picaxeforum.co.uk/showthread.php?t=12400

 

[demonicpicaxeguy]

just curious you said adding more battery power isn't option, but what about a small solar panel?

 

[tchapin]

On the 28X project board, all outputs and the 4MHz resonator are tied to ground with 10K resistors. No floating voltages on the analog inputs or any other pins.

According the the PIC datasheet, at 5V the likely culprits for ~125uA power sink are VP6 REF current, BOR, Comparators (CMxCONx), CVRef,

all ADC, OSCCON, CMxCONx, and registers using CVRef are off

PCON bit4 can be used to toggle BOR and it was working properly (~200 uA with enablebod, ~125 uA with disablebod for 'bad chip').

I never found a way to directly turn off the VP6 current which I assume is the 0.6V reference used in ADC. Turning off the ADC will hopefully take care of this.

Disablebod and enablebod commands were reversed until late last year when a new compiler revision fixed the problem. They work correctly on the 28X1 now.

I can't use solar panel, the instrument is submerged in streams/lakes and is under ice for ~6 months during winter. I can probably add some more battery capacity for the picaxe controller but since one group of 28X1 chips and the 28X2s have the requisite low power, I figured it must be a firmware or peripheral issue. Looks like these chips have some problem that I haven't figured out and can't fix.

Thanks for all your suggestions.

 

[Dippy]

Very odd.
You said chips#1-3 and chip 4 all had same firmware and same batch.
Yet, chip 4 > 103uA

I assume you tested them all under exactly same physical conditions and with all peripherals switched OFF.

So, that's:-
ADCON0.0 = 0
Disable BOD (I dunno how config reg is set so use command)
CM1CON0.7 = 0
CM2CON0.7 = 0
VRCON.7 = 0 (CVref circuit powered down)

I dunno about VP6, but guessing its something related to the reference module.

Maybe worth looking at C1RSEL and C2RSEL too. (clutching at straws).

Many of the above default OFF after POR or BOR but I don't know what firmware does.

Noting:
"Power-down current is measured with the part in Sleep mode, with all I/O pins in high-impedance state and tied to VDD."

Questions.
Does it affect your figures if you run some code and then SLeep?
Or, if you do Sleep as your first command?
All your outputs definitely low?
Can you set the outputs to inputs?

Personally, if I were 100% confident with my testing then I'd get in touch with Microchip Technical.

 

[hippy]

I tested a 28X1 using an uncalibrated meter of unknown accuracy and got results in the same ballpark; ~130uA. That was on a breadboard, all inputs floating, outputs not connected, just the minimal download circuit.

With ENABLEBOD the draw is higher, so DISABLEBOD is not the culprit. Examining all the SFR's which control peripheral devices and there seems to be nothing erroneous which would account for something being turned on.

What is intriguing is that Chips 1-3 and Chip 4, same firmware, same batch, very different results. It should be same hardware initialisation, same firmware initialisation, same Basic program, same outcome. It is a mystery as to what is going on.

Are the results consistantly repeatable ?

 

[tchapin]

I run a register PEEK loop program which PEEKs registers 0-511 and outputs to terminal screen. I run this program on the same 28X project board with both the 'good chip' (1.8uA) and 'bad chip' (125 uA). I then compare which register values are different to make sure there isn't some more obscure register that's in a different state. According to the manual PEEK/POKE only goes up to register 255. I am able to access registers 256-511 if I use a word variable (w1) with PEEK instead of a byte variable (b1). I think I read somewhere that registers >255 are not user accessible but I do seem to be able to POKE them as well.

3AA voltage = 4.7V, no problems with voltage

Dippy, these peripherals are all OFF

ADCON, register 31 = 0
ADCON1, register 159 = 0
CM1CON0, register 263 = 0
CM2CON0, register 264 = 0
CM2CON1, register 265 = 0
VRCON, register 151 = 0

The only registers that show a difference between the 'good chip' and 'bad chip' are:

TMR0, register 1
ADRESL, register 158, A/D results
TMR0, register 257 (bank2)
unknown general purpose register 414
occasionally TMR1L, register 14

You'd expect these to be different since most are timers and none of these are 'OFF/ON' (i.e 0/1) registers. I can poke them to 0 and still get same 125uA current draw.

<Maybe worth looking at C1RSEL and C2RSEL too. (clutching at straws).

C1RSEL and C2RESL bits on CM2CON1 register are both 0

Yes, all the chips give same current draw as originally measured, both 'good' and 'bad', even on different 28X project boards. Current draw very stable and is not floating.

<Does it affect your figures if you run some code and then SLeep?
<Or, if you do Sleep as your first command?

order of SLEEP has no effect

<All your outputs definitely low?

All pins measured at 0V except 4.7V on +V pin and reset pin.

<Can you set the outputs to inputs?

switching pins on port A and C (A0-A7, C0-C7) to inputs or outputs doesn't affect sleep current, still 125uA.

The stability of the current draw on different boards in all the test scenarios still suggests it's a chip to chip variation.

Thanks for your suggestions.

 

[Dippy]

Well, I'm at a complete loss.

Unless you get some reply from Rev-Ed Technical, I would suggest you contact Microchip technical to ask if there is any silicon funnies in that batch.

 

[Technical]

We also can't explain why same PIC batch with same firmware give different values. Our guess would also be a silicon issue somewhere over which we have no control.