328P sleep current wildly different between two copies

Go To Last Post
121 posts / 0 new

Pages

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

Scroungre wrote:

It's not entirely impossible that you did get two different chips - but instead of your thought that one was bad - perhaps it's that the other one was a wacky statistical outlier.  You got one awesome one - and the other was normal, not defective.  You should be happy.  S.

 

But of course that's not what happened.  I had one old Mini that sleeps properly.  *ALL five* of the new Minis, purchased from two different sources, were bad.  And I mean bad.  If the sleep current is out of spec (per the datasheet) by two to three orders of magnitude, that isn't "normal".  That is completely out of spec.

Last Edited: Fri. Jul 31, 2020 - 02:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 > The whole issue is easily solved.

 

Sounds good, but there is one additional requirement, and that is the date code.  If the chips I have are genuine, then we have one older chip and several newer ones, all with the same revision code, but the old one works and the new ones don't work.  It may be that none of my chips are genuine, but they might be.  So to settle the issue you have to test a recent chip that is known to be genuine.  Do you have such a chip, either AU or PU?  The date codes on my bad chips are 1936 and 1942, so you would want to test something newer than that, but preferably a code from 2020.  Kevin has ordered new supply from Digikey, and has requested a 2020 date code.  If they send him that, we will know the answer next week.

 

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

You could help put this to rest yourself if you only posted a .hex file of what's on the target.  Use avrdude to read flash, rather than pulling the .hex file from the Arduino IDE's build directory.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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


OK, a few more tests.

 

Dug out my uCurrent. Running at at 1mV/1uA.

 

 

 

If I run my original code...

 

        /* Prepare the sleep in power down mode*/
        SMCR |= (1<<SE) | (0<<SM2) | (1<<SM1) | (0<<SM0);
        /* Disable brown out detection in sleep */
        tmp = MCUCR | (1<<BODS) | (1<<BODSE);
        MCUCR = tmp;
        MCUCR = tmp & (~(1<<BODSE));
        /* Enter sleep mode */
        #asm("sleep");

 

I get this...

 

 

...kinda what we expect, something sub 1uA.

 

However, do this...

 

        /* Prepare the sleep in power down mode*/
        SMCR |= (1<<SE) | (0<<SM2) | (1<<SM1) | (0<<SM0);
        /* Disable brown out detection in sleep */
        tmp = MCUCR | (1<<BODS) | (1<<BODSE);
        MCUCR = tmp;
        MCUCR = tmp & (~(1<<BODSE));
        delay_us(100);
        /* Enter sleep mode */
        #asm("sleep");

 

NOTE THE DELAY_US(100)...and I get this...

 

 

 

So, the question I posed back in #101 https://www.avrfreaks.net/commen... is very relevant.

 

I don't do Arduino. But if someone who does could check the generated code we might learn something.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Last Edited: Fri. Jul 31, 2020 - 03:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Peabody wrote:

Sounds good, but there is one additional requirement, and that is the date code.

 

I believe the date code to be irrelevant. The die tracking number and revision is all we need.

 

I also still think that you have a measurement problem that is giving you duff information.

 

I also think that the Arduino code is incorrect.

 

Would you like to try the code I have that seems to give the right behaviour? The .hex file is attached.

 

 

Attachment(s): 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Brian Fairchild wrote:

Peabody wrote:

Sounds good, but there is one additional requirement, and that is the date code.

 

I believe the date code to be irrelevant. The die tracking number and revision is all we need.

 

 

I have an older chip that sleeps at 1uA, and a newer chip that sleeps at 150uA.  Both are marked 35473D.  By the way, does the chip you're testing have a date code?  Just curious.

 

Quote:

I also still think that you have a measurement problem that is giving you duff information.

 

Then you have to explain why I don't get duff information with the old chip.  Only with the new ones.

 

Quote:

I also think that the Arduino code is incorrect.

 

Again, only incorrect for the new chips?   And incorrect in what way?

 

Quote:

Would you like to try the code I have that seems to give the right behaviour? The .hex file is attached.

 

Would that be your C code above but without the delay?  I have already tested the BOD delay, with these results:

 

Old chip with no BOD delay  -  <1uA

Old chip with BOD delay  -  20uA

New chip with no BOD delay - 150uA

New chip with BOD delay - 170uA

 

So as you can see, the failure to disable BOD is worth 20uA on both chips.  So that's not the explanation for what I'm seeing.

 

But before I try to flash your code, let me ask you in advance what that will decide.  If the new chips sleep at 1uA with your code, then you've solved my problem, and get my sincere thanks, and my apologies to Microchip for even suspecting that they've f-ed up the 328P.  But what if I still get 150uA?  What will be your conclusion?  Will it still be my fault that I get 150uA, but only on the new chips?

 

 

 

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

But before I try to flash your code,

Why are you trying to avoid a possible solution?  Have you tried the  provided code or not?  If it works, then you can investigate why it works. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Peabody wrote:
Then you have to explain why I don't get duff information with the old chip.  Only with the new ones.

joeymorin wrote:
Process variations from different fabs may be the only thing at work here, with the 'bad' chips misbehaving in a way that shows your high sleep current, and the 'good' chips misbehaving in another way which does not.

 

Peabody wrote:
Again, only incorrect for the new chips?   And incorrect in what way?

joeymorin wrote:
You could help put this to rest yourself if you only posted a .hex file of what's on the target.  Use avrdude to read flash, rather than pulling the .hex file from the Arduino IDE's build directory.

 

 

Peabody wrote:
But what if I still get 150uA?  What will be your conclusion?
The conclusion will still be that we don't have enough information to draw a conclusion.  No-one, apart from you, has drawn conclusions here.  But you seem to have been reluctant to undertake some of the tests which have been suggested in this thread.  Several members have pointed out potential problems in your test methodology, yet we haven't heard much from you beyond, effectively, "I know what I'm doing".  Until the test methodology is show to be sound, your test results are going to be met with scepticism, and additional questions, especially since no-one has been able to reproduce them.

 

To misquote a fictional figure:  "Once you have eliminated the impossible, whatever remains, however improbable, must be the truth."

 

You have yet to arrive at a point where you can claim to have eliminated the impossible, and the evidence you present in support of your conclusion is at best circumstantial.  You must do the work to eliminate the most likely scenarios, but you have yet to address even the "low-hanging fruit".

 

EDIT: sp

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Fri. Jul 31, 2020 - 11:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think it's pretty clear that there's no point in my doing anything further with this.  I really came here hoping someone would already have information on this problem, not to convince anyone of anything.  It's clear that most here don't accept my resuts as valid, and that's ok.  But it's also clear to me that nothing I could do that still produces sleep current of 150uA would be accepted as valid.  So there's no reason to keep going with this.  I would just suggest that to my knowledge no one here has even tried to reproduce my results on a 328P with a date code similar to the ones on my bad chips.  If anyone would like to do that, I would accept the results.

 

In any case, I've now sent my stuff to Kevin, and he confirmed that he received the first package this morning.  Since he has all the right gear and the expertise, i'm willing to go with whatever he comes up with.  As  I said before, he has also ordered current stock from Digikey, which will permit the more important test.  It's possible he will make a video, but if not I will post when I know more.

 

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

Fair enough.  I had not read the spec sheet before commenting.  's worth noting that Brian Fairchild's meter says 0.4uA, not <0.2.  Perhaps the die temperature is more than 25C.  Or he needs a better meter (crowdfund!).  I'm guessing that gizmo on the end of the breadboard is a current measuring device, and how leaky are those caps?

 

If you write the code in assembler you can count the cycles...  ;-)  S.

 

Edited to add:  Looks like he found a better meter.  My bad for not reading through!

 

Last Edited: Sat. Aug 1, 2020 - 10:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe a bit late, but I'll make one more stupid suggestion:  Smoke all the caps off your Arduino minis.  Start with the "big" electrolytic, if there is one.  Yeah, you lose decoupling, but it's a valid test.  Doesn't take much leakage to blow away 100µA.

 

Another stupid suggestion:  Clean the board.  If they decided to skip the 'cleaning' part, or got it wrong, leftover flux could easily carry off 100µA.  S.

 

PS: Might also suggest to Brian Fairchild:  Pull the chip from your breadboard, and measure the currents just through the caps... 

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

Brian Fairchild wrote:

Would you like to try the code I have that seems to give the right behaviour? The .hex file is attached.

 

I tested your hex against 2 ATMega328P in my socketed test jig for ATMegax8

 

Date Code 1933
Pulled from Chinese sourced Nano

Top Markings

  Mega328P
  U-TW
  35473D
  1933D1S

Bottom Markings
  None printed, just the mould ejection pin codes

Spin Current 3.0mA
Brian Fairchild Hex Current 175uA

avrdude: safemode: lfuse reads as E2
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as 5
avrdude: safemode: Fuses OK (H:05, E:DF, L:E2)

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

Date Code 1648
Purchased from Chinese vendor couple years back

Top Markings

   Mega328P
   AU 1648

Bottom Markings

  A8TY2A
  35473D
  1-P
  1648 e3  (e is lower case but same height as 3)

Die code marked on bottom

Spin Current 3.3mA
Brian Fairchild Hex Current 0.1uA

avrdude: safemode: lfuse reads as E2
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as 5
avrdude: safemode: Fuses OK (H:05, E:DF, L:E2)

 

 

 

 

 

Edit: Typo'd the (die?) code on one of the ICs, they are both the same, 35473D

Last Edited: Sun. Aug 2, 2020 - 07:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:

...'s worth noting that Brian Fairchild's meter says 0.4uA, not <0.2...

 

I note your correction but it's worth noting for people stumbling across this thread in future that any meter will be spec'd as "y.yy% + x digits". So, for example, if we have a meter that's spec'd as 1% + 10 digits that means if it displays 1.000V the actual result could be anywhere...

 

(1.000 + 1%) + '10' ie 1.010 + .010 = 1.020 or

(1.000 - 1%) - '10' ie 0.990 - .010 = 0.980

 

Ironically, if you're looking for a meter which will be measuring near the bottom of a range, it's sometimes better to buy a meter with a worse percentage but smaller number of digits.

 

[can you tell my first real job was working in a test equipment calibration department?]

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

sleemanj wrote:

Brian Fairchild wrote:

Would you like to try the code I have that seems to give the right behaviour? The .hex file is attached.

 

I tested your hex against 2 ATMega328P in my socketed test jig for ATMegax8

 

Brilliant. Thanks. It's nice that someone else can duplicate the problem.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

So, I've been grubbing around in my chip drawers and have found a DIP28 328PU with date code 1924 which would seem to put it in the same timeframe as the chips that exhibit the problem. And guess what it measures when using the .hex file I posted above?.....

 

0.1uA +/- some small error

 

The plot thickens.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Brian Fairchild wrote:

Ironically, if you're looking for a meter which will be measuring near the bottom of a range, it's sometimes better to buy a meter with a worse percentage but smaller number of digits.

 

I'd guess that means if you're using any meter near its limits, high or low, then you're probably using the wrong meter.  But whadda I know?  frown  S.

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

ATMega328P in my socketed test jig

I guess that the power supply bypass caps are under the board? Or non existent? 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

A quick poke around shows a decent 100µF 6.3V electrolytic cap is expected to leak tens of microamps.  No, that won't take you to 150, but if you need 0.2?  Yeah.  Watch those capacitors...  S.

 

https://www.digikey.com/product-...

 

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

Brian Fairchild wrote:
And guess what it measures when using the .hex file I posted above?.....

 

0.1uA +/- some small error 

 

Enviable.
My latest achievement: 0.38µA @ 3.0V, 26°C.

 

/*-------------------------------------------------------------------
Blink and sleep
Arduino Pro Mini Board, Atmega328P, Internal RC Oscillator, CKDIV8
LED  = PB5 = 13(Ard)
INT0 = PD2 =  2(Ard)

MOSI = PB3 = 11(Ard)
MISO = PB4 = 12(Ard)
SCK  = PB5 = 13(Ard)
----------------------------------------------------------------------*/

#include <avr/io.h>
#define F_CPU 1000000			// 8MHz/8
#include <util/delay.h>
#include <avr/interrupt.h>
#include <avr/sleep.h>

int main(void)
{
  DDRB |= (1<<DDB5);			// output
  PORTD |= (1<<PD2);			// pullup
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);	// sleep mode
  sei();				// enable interrupts

  while(1)
  {
    for(uint8_t i=0;i<5;i++)
    {
      PORTB |= (1<<PB5);		// LED on
      _delay_ms(50);
      PORTB &= ~(1<<PB5);		// LED off
      _delay_ms(450);
    }
  EIMSK |= (1<<INT0);			// enable INT0
  sleep_mode();
  EIMSK &= ~(1<<INT0);			// disable INT0
  }
}

 

The truth is more important than the facts.

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

Scroungre wrote:
Clean the board.  If they decided to skip the 'cleaning' part, or got it wrong, leftover flux could easily carry off 100µA.  S.

I think someone may have mentioned that the board might contribute some leakage ... ?

 

cheeky

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...

Pages