UC3B0256 wrong power consumption after DeepStop

Go To Last Post
29 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys,

I'm testing my UC3B0256 sleep mode power consumption.

I downloaded a very simple DeepStop sleep code to its flash, and after repower on, the current meter still give me about 4mA, which means the MCU is not in sleep yet. But then reading the General Registers shows the PC really always stay at 0x80002086 where the sleep code situates:

80002086:	e9 b0 00 04 	sleep	0x4

so why?

Here is my C code:

#include "gpio.h"
#include "flashc.h"
#include "pm.h"

int main(void)
{
  SLEEP(AVR32_PM_SMODE_SHUTDOWN);
  while(1)
  {
  	;
  }
}

and the makefile sources:

# C source files
CSRCS = \
  $(DRVR_PATH)/INTC/intc.c \
  $(DRVR_PATH)/PM/pm.c \
  $(DRVR_PATH)/GPIO/gpio.c \
  $(DRVR_PATH)/FLASHC/flashc.c \
  ../../pm_example2.c

Here is its compiled lss file:


uc3b0256-pm_example2.elf:     file format elf32-avr32

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .reset        00002008  80000000  80000000  00001000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rela.got     00000000  80002008  80002008  00003008  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .text         000000d4  80002008  80002008  00003008  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .exception    00000200  80002200  80002200  00003200  2**9
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  4 .rodata       00000090  80002400  80002400  00003400  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .dalign       00000004  00000004  00000004  00004004  2**0
                  ALLOC
  6 .bss          000000a0  00000008  00000008  00004008  2**2
                  ALLOC
  7 .heap         00006f58  000000a8  000000a8  000040a8  2**0
                  ALLOC
  8 .comment      00000096  00000000  00000000  000040a8  2**0
                  CONTENTS, READONLY
  9 .debug_aranges 000004b0  00000000  00000000  0000413e  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_pubnames 00000d91  00000000  00000000  000045ee  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_info   0000c597  00000000  00000000  0000537f  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_abbrev 0000076f  00000000  00000000  00011916  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_line   00000e8e  00000000  00000000  00012085  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_frame  00000e8c  00000000  00000000  00012f14  2**2
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_str    00000709  00000000  00000000  00013da0  2**0
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_loc    000015d6  00000000  00000000  000144a9  2**0
                  CONTENTS, READONLY, DEBUGGING
 17 .stack        00001000  00007000  00007000  00016000  2**0
                  ALLOC
Disassembly of section .reset:

80000000 <_trampoline>:
80000000:	e0 8f 10 00 	bral	80002000 
	...

80002000 :
80002000:	48 1f       	lddpc	pc,80002004 
80002002:	00 00       	add	r0,r0
80002004:	80 00       	ld.sh	r0,r0[0x0]
80002006:	20 8c       	sub	r12,8
Disassembly of section .text:

80002008 <_get_interrupt_handler>:
 *
 * \note Taken and adapted from Newlib.
 */
__int_handler _get_interrupt_handler(unsigned int int_lev)
{
80002008:	eb cd 40 80 	pushm	r7,lr
8000200c:	1a 97       	mov	r7,sp
8000200e:	20 4d       	sub	sp,16
80002010:	ef 4c ff f4 	st.w	r7[-12],r12
  // ICR3 is mapped first, ICR0 last.
  // Code in exception.S puts int_lev in R12 which is used by AVR32-GCC to pass
  // a single argument to a function.
  unsigned int int_grp = (&AVR32_INTC.icr3)[INT3 - int_lev];
80002014:	ee f8 ff f4 	ld.w	r8,r7[-12]
80002018:	f0 08 11 03 	rsub	r8,r8,3
8000201c:	a3 68       	lsl	r8,0x2
8000201e:	e0 28 f6 00 	sub	r8,62976
80002022:	70 08       	ld.w	r8,r8[0x0]
80002024:	ef 48 ff f8 	st.w	r7[-8],r8
  unsigned int int_req = AVR32_INTC.irr[int_grp];
80002028:	fe 79 08 00 	mov	r9,-63488
8000202c:	ee f8 ff f8 	ld.w	r8,r7[-8]
80002030:	a3 68       	lsl	r8,0x2
80002032:	12 08       	add	r8,r9
80002034:	f0 f8 01 00 	ld.w	r8,r8[256]
80002038:	ef 48 ff fc 	st.w	r7[-4],r8

  // As an interrupt may disappear while it is being fetched by the CPU
  // (spurious interrupt caused by a delayed response from an MCU peripheral to
  // an interrupt flag clear or interrupt disable instruction), check if there
  // are remaining interrupt lines to process.
  // If a spurious interrupt occurs, the status register (SR) contains an
  // execution mode and interrupt level masks corresponding to a level 0
  // interrupt, whatever the interrupt priority level causing the spurious
  // event. This behavior has been chosen because a spurious interrupt has not
  // to be a priority one and because it may not cause any trouble to other
  // interrupts.
  // However, these spurious interrupts place the hardware in an unstable state
  // and could give problems in other/future versions of the CPU, so the
  // software has to be written so that they never occur. The only safe way of
  // achieving this is to always clear or disable peripheral interrupts with the
  // following sequence:
  // 1: Mask the interrupt in the CPU by setting GM (or IxM) in SR.
  // 2: Perform the bus access to the peripheral register that clears or
  //    disables the interrupt.
  // 3: Wait until the interrupt has actually been cleared or disabled by the
  //    peripheral. This is usually performed by reading from a register in the
  //    same peripheral (it DOES NOT have to be the same register that was
  //    accessed in step 2, but it MUST be in the same peripheral), what takes
  //    bus system latencies into account, but peripheral internal latencies
  //    (generally 0 cycle) also have to be considered.
  // 4: Unmask the interrupt in the CPU by clearing GM (or IxM) in SR.
  // Note that steps 1 and 4 are useless inside interrupt handlers as the
  // corresponding interrupt level is automatically masked by IxM (unless IxM is
  // explicitly cleared by the software).
  //
  // Get the right IRQ handler.
  //
  // If several interrupt lines are active in the group, the interrupt line with
  // the highest number is selected. This is to be coherent with the
  // prioritization of interrupt groups performed by the hardware interrupt
  // controller.
  //
  // If no handler has been registered for the pending interrupt,
  // _unhandled_interrupt will be selected thanks to the initialization of
  // _int_line_handler_table_x by INTC_init_interrupts.
  //
  // exception.S will provide the interrupt handler with a clean interrupt stack
  // frame, with nothing more pushed onto the stack. The interrupt handler must
  // manage the `rete' instruction, what can be done thanks to pure assembly,
  // inline assembly or the `__attribute__((__interrupt__))' C function
  // attribute.
  return (int_req) ? _int_handler_table[int_grp]._int_line_handler_table[32 - clz(int_req) - 1] : NULL;
8000203c:	ee f8 ff fc 	ld.w	r8,r7[-4]
80002040:	58 08       	cp.w	r8,0
80002042:	c1 40       	breq	8000206a <_get_interrupt_handler+0x62>
80002044:	ee f8 ff f8 	ld.w	r8,r7[-8]
80002048:	48 d9       	lddpc	r9,8000207c <_get_interrupt_handler+0x74>
8000204a:	a3 78       	lsl	r8,0x3
8000204c:	12 08       	add	r8,r9
8000204e:	70 19       	ld.w	r9,r8[0x4]
80002050:	ee f8 ff fc 	ld.w	r8,r7[-4]
80002054:	f0 08 12 00 	clz	r8,r8
80002058:	f0 08 11 1f 	rsub	r8,r8,31
8000205c:	a3 68       	lsl	r8,0x2
8000205e:	f2 08 00 08 	add	r8,r9,r8
80002062:	70 08       	ld.w	r8,r8[0x0]
80002064:	ef 48 ff f0 	st.w	r7[-16],r8
80002068:	c0 48       	rjmp	80002070 <_get_interrupt_handler+0x68>
8000206a:	30 08       	mov	r8,0
8000206c:	ef 48 ff f0 	st.w	r7[-16],r8
80002070:	ee f8 ff f0 	ld.w	r8,r7[-16]
}
80002074:	10 9c       	mov	r12,r8
80002076:	2f cd       	sub	sp,-16
80002078:	e3 cd 80 80 	ldm	sp++,r7,pc
8000207c:	80 00       	ld.sh	r0,r0[0x0]
8000207e:	24 00       	sub	r0,64

80002080 
: * PLL0 output. * */ int main(void) { 80002080: eb cd 40 80 pushm r7,lr 80002084: 1a 97 mov r7,sp SLEEP(AVR32_PM_SMODE_SHUTDOWN); 80002086: e9 b0 00 04 sleep 0x4 /* Now toggle LED0 using a GPIO */ while(1) { ; } 8000208a: c0 08 rjmp 8000208a 8000208c <_stext>: 8000208c: 48 cd lddpc sp,800020bc 8000208e: 48 d0 lddpc r0,800020c0 80002090: e3 b0 00 01 mtsr 0x4,r0 80002094: d5 53 csrf 0x15 80002096: 48 c0 lddpc r0,800020c4 80002098: 48 c1 lddpc r1,800020c8 8000209a: 02 30 cp.w r0,r1 8000209c: c0 62 brcc 800020a8 8000209e: 48 c2 lddpc r2,800020cc 800020a0 : 800020a0: a5 05 ld.d r4,r2++ 800020a2: a1 24 st.d r0++,r4 800020a4: 02 30 cp.w r0,r1 800020a6: cf d3 brcs 800020a0 800020a8 : 800020a8: 48 a0 lddpc r0,800020d0 800020aa: 48 b1 lddpc r1,800020d4 800020ac: 02 30 cp.w r0,r1 800020ae: c0 62 brcc 800020ba 800020b0: 30 02 mov r2,0 800020b2: 30 03 mov r3,0 800020b4 : 800020b4: a1 22 st.d r0++,r2 800020b6: 02 30 cp.w r0,r1 800020b8: cf e3 brcs 800020b4 800020ba : 800020ba: 48 8f lddpc pc,800020d8 800020bc: 00 00 add r0,r0 800020be: 80 00 ld.sh r0,r0[0x0] 800020c0: 80 00 ld.sh r0,r0[0x0] 800020c2: 22 00 sub r0,32 800020c4: 00 00 add r0,r0 800020c6: 00 08 add r8,r0 800020c8: 00 00 add r0,r0 800020ca: 00 08 add r8,r0 800020cc: 80 00 ld.sh r0,r0[0x0] 800020ce: 24 90 sub r0,73 800020d0: 00 00 add r0,r0 800020d2: 00 08 add r8,r0 800020d4: 00 00 add r0,r0 800020d6: 00 a8 st.w r0++,r8 800020d8: 80 00 ld.sh r0,r0[0x0] 800020da: 20 80 sub r0,8 Disassembly of section .exception: 80002200 <_evba>: 80002200: c0 08 rjmp 80002200 <_evba> ... 80002204 <_handle_TLB_Multiple_Hit>: 80002204: c0 08 rjmp 80002204 <_handle_TLB_Multiple_Hit> ... 80002208 <_handle_Bus_Error_Data_Fetch>: 80002208: c0 08 rjmp 80002208 <_handle_Bus_Error_Data_Fetch> ... 8000220c <_handle_Bus_Error_Instruction_Fetch>: 8000220c: c0 08 rjmp 8000220c <_handle_Bus_Error_Instruction_Fetch> ... 80002210 <_handle_NMI>: 80002210: c0 08 rjmp 80002210 <_handle_NMI> ... 80002214 <_handle_Instruction_Address>: 80002214: c0 08 rjmp 80002214 <_handle_Instruction_Address> ... 80002218 <_handle_ITLB_Protection>: 80002218: c0 08 rjmp 80002218 <_handle_ITLB_Protection> ... 8000221c <_handle_Breakpoint>: 8000221c: c0 08 rjmp 8000221c <_handle_Breakpoint> ... 80002220 <_handle_Illegal_Opcode>: 80002220: c0 08 rjmp 80002220 <_handle_Illegal_Opcode> ... 80002224 <_handle_Unimplemented_Instruction>: 80002224: c0 08 rjmp 80002224 <_handle_Unimplemented_Instruction> ... 80002228 <_handle_Privilege_Violation>: 80002228: c0 08 rjmp 80002228 <_handle_Privilege_Violation> ... 8000222c <_handle_Floating_Point>: 8000222c: c0 08 rjmp 8000222c <_handle_Floating_Point> ... 80002230 <_handle_Coprocessor_Absent>: 80002230: c0 08 rjmp 80002230 <_handle_Coprocessor_Absent> ... 80002234 <_handle_Data_Address_Read>: 80002234: c0 08 rjmp 80002234 <_handle_Data_Address_Read> ... 80002238 <_handle_Data_Address_Write>: 80002238: c0 08 rjmp 80002238 <_handle_Data_Address_Write> ... 8000223c <_handle_DTLB_Protection_Read>: 8000223c: c0 08 rjmp 8000223c <_handle_DTLB_Protection_Read> ... 80002240 <_handle_DTLB_Protection_Write>: 80002240: c0 08 rjmp 80002240 <_handle_DTLB_Protection_Write> ... 80002244 <_handle_DTLB_Modified>: 80002244: c0 08 rjmp 80002244 <_handle_DTLB_Modified> ... 80002250 <_handle_ITLB_Miss>: 80002250: c0 08 rjmp 80002250 <_handle_ITLB_Miss> ... 80002260 <_handle_DTLB_Miss_Read>: 80002260: c0 08 rjmp 80002260 <_handle_DTLB_Miss_Read> ... 80002270 <_handle_DTLB_Miss_Write>: 80002270: c0 08 rjmp 80002270 <_handle_DTLB_Miss_Write> ... 80002300 <_handle_Supervisor_Call>: 80002300: c0 08 rjmp 80002300 <_handle_Supervisor_Call> ... 80002304 <_int0>: 80002304: e1 bc 00 00 mfsr r12,0x0 80002308: f9 dc c2 c3 bfextu r12,r12,0x16,0x3 8000230c: 58 6c cp.w r12,6 8000230e: c0 83 brcs 8000231e <_int0_normal> 80002310: 40 0c lddsp r12,sp[0x0] 80002312: 50 6c stdsp sp[0x18],r12 80002314: 40 1c lddsp r12,sp[0x4] 80002316: 50 7c stdsp sp[0x1c],r12 80002318: 40 3c lddsp r12,sp[0xc] 8000231a: 2f ad sub sp,-24 8000231c: d6 03 rete 8000231e <_int0_normal>: 8000231e: 30 0c mov r12,0 80002320: f0 1f 00 25 mcall 800023b4 80002324: 58 0c cp.w r12,0 80002326: f8 0f 17 10 movne pc,r12 8000232a: d6 03 rete 8000232c <_int1>: 8000232c: e1 bc 00 00 mfsr r12,0x0 80002330: f9 dc c2 c3 bfextu r12,r12,0x16,0x3 80002334: 58 6c cp.w r12,6 80002336: c0 83 brcs 80002346 <_int1_normal> 80002338: 40 0c lddsp r12,sp[0x0] 8000233a: 50 6c stdsp sp[0x18],r12 8000233c: 40 1c lddsp r12,sp[0x4] 8000233e: 50 7c stdsp sp[0x1c],r12 80002340: 40 3c lddsp r12,sp[0xc] 80002342: 2f ad sub sp,-24 80002344: d6 03 rete 80002346 <_int1_normal>: 80002346: 30 1c mov r12,1 80002348: f0 1f 00 1b mcall 800023b4 8000234c: 58 0c cp.w r12,0 8000234e: f8 0f 17 10 movne pc,r12 80002352: d6 03 rete 80002354 <_int2>: 80002354: e1 bc 00 00 mfsr r12,0x0 80002358: f9 dc c2 c3 bfextu r12,r12,0x16,0x3 8000235c: 58 6c cp.w r12,6 8000235e: c0 83 brcs 8000236e <_int2_normal> 80002360: 40 0c lddsp r12,sp[0x0] 80002362: 50 6c stdsp sp[0x18],r12 80002364: 40 1c lddsp r12,sp[0x4] 80002366: 50 7c stdsp sp[0x1c],r12 80002368: 40 3c lddsp r12,sp[0xc] 8000236a: 2f ad sub sp,-24 8000236c: d6 03 rete 8000236e <_int2_normal>: 8000236e: 30 2c mov r12,2 80002370: f0 1f 00 11 mcall 800023b4 80002374: 58 0c cp.w r12,0 80002376: f8 0f 17 10 movne pc,r12 8000237a: d6 03 rete 8000237c <_int3>: 8000237c: e1 bc 00 00 mfsr r12,0x0 80002380: f9 dc c2 c3 bfextu r12,r12,0x16,0x3 80002384: 58 6c cp.w r12,6 80002386: c0 83 brcs 80002396 <_int3_normal> 80002388: 40 0c lddsp r12,sp[0x0] 8000238a: 50 6c stdsp sp[0x18],r12 8000238c: 40 1c lddsp r12,sp[0x4] 8000238e: 50 7c stdsp sp[0x1c],r12 80002390: 40 3c lddsp r12,sp[0xc] 80002392: 2f ad sub sp,-24 80002394: d6 03 rete 80002396 <_int3_normal>: 80002396: 30 3c mov r12,3 80002398: f0 1f 00 07 mcall 800023b4 8000239c: 58 0c cp.w r12,0 8000239e: f8 0f 17 10 movne pc,r12 800023a2: d6 03 rete 800023a4 : 800023a4: 00 00 01 04 40 00 01 2c 80 00 01 54 c0 00 01 7c ....@..,...T...| 800023b4: 80 00 20 08 00 00 00 00 00 00 00 00 00 00 00 00 .. ............. ...

Cheng

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do you measure the 4mA? on the EVK1101?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

no, it's not EVK1101, it's my own PCB, and I think this 4mA is to the MCU, not other ICs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i know the example is for EVK1101, but in my main function, this is just a sleep command, so then the UC3B on my PCB should also sleep, right? And by default, the MCU should be running on its internal RCOSC, right?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In order to reduce power consumption, you should :
* enable pull-up for gpios (it is dependant to your application) - using gpio_enable_pin_pull_up(xx); function -
* disconnect Jtag mkII, power on/off your target and measure consumption again. Because when device remains connected to jtag after power on/off, clock stills alive.

Quote:

And by default, the MCU should be running on its internal RCOSC, right?

Yes, that's right

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi, Perlves,

All of the GPIO pins of MCU should be input (high z) by default, right? So I think this shouldn't consume much power.

yes, I did measure the current after disconnecting JTAG and recycling the power.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

All of the GPIO pins of MCU should be input (high z) by default, right?

Yes if you want to reduce power consumption excepted GPIOs you use in your application

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok, so then my MCU just shouldn't consume 4mA at the DeepStop mode. But I have another identical PCB without the MCU mounted and it's current consumption is almost nothing (which is correct), so this means it must be the MCU which suck the power, but I can't see any problem in my code....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just tried with Static mode, it's the same.

80002086:	e9 b0 00 05 	sleep	0x5
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you placed in your code ?


#include "gpio.h"
#include "flashc.h"
#include "pm.h"

int main(void)
{
  // Enable Pull Up for all gpio unused in your application here: gpio_enable_pin_pull_up(xx);
  SLEEP(AVR32_PM_SMODE_SHUTDOWN);
  while(1)
  {
     ;
  }
}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

not yet, but I don't think it will help, because if I pulled up all my GPIO pins, then those pins connected to other ICs would actually start out sourcing current, right? it would increase the total current.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm checking the description for SLEEP,

Quote:

SLEEP – Set CPU Activity Mode
Architecture revision:
Architecture revision1 and higher.
...

Note:
The sleep instruction is a privileged instruction, and will trigger a Privilege Violation exception if executed in user mode.

My MCU is -UES, so it should be revision 1, right?

Is this Privilege Violation exception a problem for me?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
, then those pins connected to other ICs would actually start out sourcing current, right?

Yes, you should enable pull up only on pins on which it is possible

Quote:

My MCU is -UES, so it should be revision 1, right?

Yes

Quote:

Is this Privilege Violation exception a problem for me?

No, by default the application is in privileged mode. So this is no problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok, then I think the code should let MCU sleep, but the current is wrong...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you tried to execute a code to see if there is difference between 'MCU sleep state' and 'MCU not sleep state', for example:

#include "gpio.h"
#include "flashc.h"
#include "pm.h"

int main(void)
{
  // Enable Pull Up for all gpio unused in your application here: gpio_enable_pin_pull_up(xx);
  while(1)
  {
     // If external condition, force MCU in 'sleep state'
     {
        SLEEP(AVR32_PM_SMODE_SHUTDOWN);
     }
     // Else, let MCU in 'not sleep state'

  }
} 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

not yet, but I can try it.

But I did downloaded two codes, one with sleep and one without before, and there was no current difference.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps your MCU goes strait out of sleep due to an interrupt or exception?

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not sure about this, but I did test like the following:

First download and run a normal code:

int main(void)
{
//  SLEEP(AVR32_PM_SMODE_STATIC);
  
  while(1)
  {
  	gpio_enable_pin_pull_up(AVR32_PIN_PA27);
  }
}

and I use JTAG to read general registers and then resume and read general registers again, and resume and read again. I can always see that the PC value are different each time a new reading from general registers, so this must means the MCU is running normally.

Then another code:

int main(void)
{
  SLEEP(AVR32_PM_SMODE_STATIC);
  
  while(1)
  {
  	gpio_enable_pin_pull_up(AVR32_PIN_PA27);
  }
}

And then do the same as the first one, I can always see that PC value stay at the same location which is the sleep code, so I think this must means the sleep code is working.

So I compare the currents in these two situations, and I can't see any significant difference, it's always about 4mA.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hum can you post your schematic and tell where do you measure the 4mA?

-sma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi, sma

I measured the current from power suplly input of my whole PCB (V_UNREG_BATTERY). this supply is about 3V, and then my DC-DC step-up regulator (MAX1724) take this and output 3.3V to MCU. the MAX1724 have about 80% efficiency. The current reading is normally around 5mA. I have an identical PCB with almost the same components on it but without MCU, 32KHz and 16MHz crystals, and this one consume almost no current (which is correct behaveior), so I think it must be the MCU which suck this 4mA.

Last Edited: Wed. Jan 9, 2008 - 11:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No the regulator and all the stuff around the UC3B could suck some of the current, could you measure it directly from the 3.3V that only powers the UC3B?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

no, i can't directly measure the UC3B, but because I measured the identical PCB just without UC3B mounted, and it gives almost no current, so I think it should be the UC3B who suck current, or it's my code which is wrong.

The things around UC3B are a temp sensor (should suck about 50uA), JTAG (no connection), USB (no connection), 40pin connector (no connection), they shouldn't suck that much current. The only thing I'm not completely sure is the ADC IOVDD pin which is connected to UC3B 3.3V supply, and other digital pins of ADC to UC3B. But as I said, I measured the other identical PCB with ADC and all the power supplies mounted, but just not the UC3B, then its current consumption is almost nothing. Since I have chip eased UC3B before any measurement and by default all the GPIO pins should be input and high z, so then all the ADC digital pins to UC3B shouldn't suck much power, right?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you checked electrical level on all I/O on UC3B in sleep mode? Is there any compatibility with external component that you drive?
It seems that I/O(s) is(are) driven to an high or low level and generate an over consumption.
Could you measure consumption with only a UC3B on PCB powered?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yes, I checked the voltages of all the connected IO pins of UC3B, all of them give me 0V except one pin connected with ADC has 3.3V. This 3.3V is output from ADC, because I get the same 3.3V on the other PCB witout UC3B.

I can't measure it with only UC3B on PCB, because I just have 5 UC3B samples and all of them have really been mounted on PCBs, so I don't have any samples left, and I don't want to remove all other components from a complete PCB to measure the current.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can UC3B change any IO pins voltage (or any other easily measurable change) when it is going to sleep, so that I can verify that the sleep code is indeed working?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After power on/off by default I/O are in high z. I adviced you to enable pull up on all I/O. I think you should check that all of these are in logical level '1'. If not, it must be a conflict and could explain this over consumption.
I/O pins state does not change during sleep mode.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok, then I will check all the pull-up.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have measured all the connected GPIO's voltages after pull-up them one by one, and I found one pin which is about 0v, the PB07 connected to ADC_DOUT1. But I think this is normal because ADC's DOUT1 will output a 0 when the it's in ideall mode, and on the other identical PCB, I get this DOUT1's resistance as about 50ohm, so it's output a 0. But as long as the PB07 is set as input, it shouldn't leak any current out.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just did another test.

I set all the ADC control pins to output 0 and STATIC sleep, then I got about 1mA from 3V input, so considering the 3V->3.3V conversion and its possible 80% efficiency, then my PCB consume 0.73mA at 3.3V, now this value is close to correct. So there must be something about undriven ADC pins which caused the abnormal 4mA. And if I let the MCU running, then I got 1.33mA out of 3V supply, so I think the sleep mode is working.