28X1 Current Consumption

R

RonHackett

Member
I have been testing the 28X1 current consumption at various processor speeds, and I'm getting some confusing results. As expected, supply current varies directly with processor speeds, but I consistently get lower readings with BOD enabled (vs. disabled). My understanding is that the reverse should be true.

Here's the code I used -

Code: 
        'disablebod
	enablebod

main:	
	setfreq m4			; set internal resonator frequency

	high 7
	pause 250			; LED on
	low  7
	wait 8
		
	setfreq k500		; set internal resonator frequency
	
	high 6			; LED on
	pause 30   			; pause a little
	low  6			; LED off
	wait 1	   		; pause a little
	
	setfreq k125		; set internal resonator frequency
	
	high 5			; LED on
	pause 8   			; pause a little
	low  5			; LED off
	pause 250	   		; pause a little
	
	setfreq k31		; set internal resonator frequency
	
	high 4			; LED on
	pause 10   			; pause a little
	low  4			; LED off
	pause 62	   		; pause a little	
	  
	goto main
The LEDs only blink briefly to let me know which speed I'm at. When current stabilizes, I take a measurement. Here's my results for four internal resonator speeds:

with "enablebod"
m4 = 992uA
k500 = 319uA
k125 = 245uA
k31 = 29uA

with"disablebod"
m4 = 1067uA
k500 = 396uA
k125 = 323uA
k31 = 107uA

Shouldn't the "disablebod" readings be the lower ones, or am I missing something here?

Also, another oddity: I almost always have to reset the 28X1 to get it to load a new program. I thought the 28X1 automatically switched back to 4MHz internal for a program load, but it doesn't seem to be happening!

Finally, I have tried this with 28x1 firmware version 1 and version 2 chips, with similar results. (I haven't been able to get a version 3 chip yet.)

If anyone can clarify why I'm getting these results, that would be great.

Thanks... Ron
 
hippy

hippy

Ex-Staff (retired)
I can't comment on the BOD effect but the difficulty in downloading is probably due to the PICAXE sitting in prolonged Waits and the same happens with Pauses, also, once the PICAXE is running other than 4MHz downloading won't work without a reset.
 
M

moxhamj

New Member
Maybe you have discovered something really useful here! Technical will no doubt have some input, but I must say that 29uA is not a lot of current. I must confess I've never measured it myself. It would be interesting to see if this can be replicated on other picaxes.
 
D

Dippy

Moderator
Hopefully I'm looking at the PCON register...

I think it's the wrong way round?
From Data Sheet PCON<4> (SBOREN):
1 = BOR enabled
0 = BOR disabled

However, 'disablebod' seems to set this to 1 (i.e. really enabled).
And 'enablebod' sets it to 0 (i.e. really disabled).
No command sets SBOREN to 1 i.e. really enabled, which is a sensible default.

My current/power measurments are the same as yours and this would confirm SBOREN status.
 
R

RonHackett

Member
Hippy: Thanks - I should have remembered that! I removed all the long delays from my code and it still requires a reset to download, so the 28X1 doesn't seem to default back to 4MHz as I thought - oh well!

Dr_Acula: I agree, 29uA is great - I plan to use this with a solar-powered data logger.

Dippy: Thanks for confirming my results - I'll just reverse "enablebod" and "disablebod" for now, since my main goal is just to reduce power consumption to a minimum.
 
hippy

hippy

Ex-Staff (retired)
@ Dippy : I agree with your reading of the manual SBOREN (bit4), 1=BOR Enabled, 0=BOR disabled.

I don't have a 28X1 to test, but it could be worth running this test program ...

Code: 
Pause 5000
SerTxd("EnableBod ")  : EnableBod  : Gosub Report
SerTxd("DisableBod ") : DisableBod : Gosub Report
End
Report:
  Pause 2000
  Peek $8E,b0
  If bit4 = 0 Then
    SerTxd(" ... Disabled",CR,LF)
  Else
    SerTxd(" ... Enabled",CR,LF)
  End If
  Return
 
D

Dippy

Moderator
2 hippy
Glad about that:) Ah, the benefits of the Data Sheet strike again!
Yes, I did do something like that, hence my diplomatic post.
Only difference was that I got it to print out all the PCON bits.

Conclusion:
For now, anyone reading this thread will need to know the command is 'inverted', or do a manual POKE.
But as this thread will disappear soon.... it needs fixing.

Also, PEEKING that register may, on some occasions be a handy diagnostic.
 
M

Mycroft2152

Senior Member
Dippy said:
2 hippy
Glad about that:) Ah, the benefits of the Data Sheet strike again!
Yes, I did do something like that, hence my diplomatic post.
Only difference was that I got it to print out all the PCON bits.

Conclusion:
For now, anyone reading this thread will need to know the command is 'inverted', or do a manual POKE.
But as this thread will disappear soon.... it needs fixing.

Also, PEEKING that register may, on some occasions be a handy diagnostic.
Click to expand...
The inversion is comfirmed on the 28X1. What about the 08M, 14M, 20M ?

Myc
 
hippy

hippy

Ex-Staff (retired)
The 08M ( and I guess all pre-X1's ) generate an explicit Poke command to write to the PCON reister ( Poke $8E,$13 - Enable, Poke $8E,$03 - disable ), the X1's use an in-built firmware command to do the job; enable and disable differ in one bit in the argument. Somewhere in the chain something I expect has got inverted.

Shouldn't be a hard problem to fix - the compiler simply has to generate the code opposite to what it is now, no changes to existing firmware required.

I'll add a note in software feedback.
 
Technical

Technical

Technical Support
Staff member
Thanks for pointing this out, it is a bug in the software compiler which we will fix in the next software release.
 
R

RonHackett

Member
Thanks to all for taking the time and trouble to check this out, and thanks to Technical for noting that a fix will be included in the next software release.

In the meantime, it's simple enough to just use the enablebod and disablebod commands "backwards".
 
You must log in or register to reply here.
Top