328P sleep current wildly different between two copies

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

Last year I bought an Arduino Pro Mini clone, 3.3V 8MHz, and removed the voltage regulator and power LED resistor.   In PWR_DOWN sleep mode it draws less than 1uA, which is what I need for battery power, and that's what the datasheet suggests it should be.

 

Last week I received two new Minis from a different source, and performed the same modifications to them.  But both of them draw 150uA in sleep when powered at 3.3V, or 330uA at 5V.  So far as I can tell, everything is the same between old and new.  That includes the boards, the modifications, the test sketch, the bootloaders, and the fuse settings.  So it's hard to see what could cause this difference unless the MCUs are different in some way.

 

The new ones have these markings:

 

Atmel
MEGA328P
U-TW
35473D
1947X5N

and
1936S2P

The old one is:

Atmel
MEGA328P
U-KR
35473D
1829R5G
 

Notice that the 330uA current at 5V is greater than you would expect if the problem is some kind of resistive leak.  And since there's almost nothing left on the Mini board but the processor, it seems that almost has to be the cause of the problem.  But I've looked through the datasheet, and don't see any version information that would account for this.  In case it matters, the new ones both had daubs of white paint covering the markings.  I don't know if that means anything.

 

If anyone has an idea about what's going on here, I'd like to hear it.  Or even an idea about how to find out where the problem lies.  I want to be able to use Pro Minis in direct battery powered situations where the processor sleeps a lot.  But it needs to sleep at 1uA, not 150.  So I need to find a resolution to this.

 

Here's my test sketch.  Thanks very much for any help.

#include <avr/sleep.h>
#include <avr/wdt.h>
int i;

void setup(){

  for (i = 0; i < 20; i++) {          // all pins to one rail or the other
    pinMode(i,OUTPUT);
    digitalWrite(i,LOW);
  }
  ADCSRA = 0;                         // disable ADC for power saving
  wdt_disable();                      // disable WDT for power saving
  set_sleep_mode (SLEEP_MODE_PWR_DOWN); // Deep sleep
  sleep_enable();
  sleep_bod_disable();                // disable brownout detector during sleep
  sleep_cpu();                        // now go to sleep

}

void loop(){
}

 

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

One other piece of information.  I rigged up my meter to measure the low side current from the Mini, then at the end of the test I grounded the Reset pin directly to power supply ground so the current flowing through the pullup resistor on Reset wouldn't be included in the current measurement.

 

Current during reset (excluding pullup resistor current):

 

New Minis - 1.15mA

Old Mini  -   0.7mA

 

That indicates to me that there is indeed a difference in these chips.  It's possible something is wrong with the new ones, or I guess they could even be mis-marked 328 parts instead of 328P.  Would that account for this difference?

 

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

Are there any resistors anywhere else?  Even 50k will blow you away (5V @50K is 100 ua).

 

Are the fuses set exactly the same in all units? Double check!

 

capacitor leakages?

 

crystals?  resonators? they can have loading differences

 

what other components are on these boards (provide a board link) 

 

Pullups?

 

 

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

Last Edited: Sun. Jul 12, 2020 - 11:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

Are there any resistors anywhere else?  Even 50k will blow you away (5V @50K is 100 ua).

 

Are the fuses set exactly the same in all units? Double check!

 

capacitor leakages?

 

crystals?  resonators? they can have loading differences

 

what other components are on these boards (provide a board link) 

 

Pullups?

 

 

 

The remaining resistors are the pullup resistor on the Reset pin and the resistor for the LED on D13 (but D13 is OUTPUT LOW).

 

The fuses, bootloader and sketch are identical on all units.  I used AvrDude to read everything out.

 

The capacitors on Vcc remain.  But I think it's unlikely the two separate copies would leak in exactly the same way.

 

It has an 8MHz resonator.  There are no separate loading capacitors.  But during the test all oscillators are turned off.

 

Here's a link to what I bought:

 

https://www.ebay.com/itm/203019631067

 

This board has a regulator and a power-on LED, both of which I have removed.  And it has an LED on D13 like most Arduinos.  It does not have a USB-to-UART chip.

 

I'm beginning to wonder if, despite the markings, these are really 328, and not 328P.  That might account for the difference in current draw.  But the markings clearly say 328P.

 

 

 

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

 

Oh here is a big one...floating inputs are very bad, and can draw a lot of current...be sure to configure all of your pins as outputs...does that help?

Do not allow any input to float!!  In the olden days, this could almost "burn up" some gates!

 

Try ditching the tanatalum/electrolytic caps from the failing board, they can be cheap and crappy.  Ceramics are somewhat less likely to have big leaks/.  Lots of tantlum end up failing as a total short....maybe these are on the way.

 

But I think it's unlikely the two separate copies would leak in exactly the same way.---if parts are from athe same batch of 50000, it could very well be a match.

 

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

My test code shown in my first post sets all IO pins to OUTPUT, LOW.

 

I replaced the remaining large capacitor - the one on Vcc - and nothing changed.  Sleep current is still 150uA.   So it wasn't leaking.

 

I posted here in the hope that someone would know something about the 328P revisions, design changes, eratta, counterfeits or whatever that might explain this problem.  It seems pretty clear that the processor is at fault.  It works ok, but just draws too much current doing so.  But if nobody has an explanation along those lines, I'll just order some from another source.  I assume as a practical matter it would be pointless to try to ask Microchip about this.

 

 

 

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

Try flashing them using ICSP instead of the bootloader.  If it doesn't work, they might actually be LGT8F328 parts.  They use SWD for programming and don't support ICSP.

 

p.s. The LGT8F328 board I bought from Electrodragon has no markings on the chip (aside from the pin 1 dot in the corner).  I bet this is intentional so that it is easy to label the chip as an Atmel part and sell it as such to unsuspecting consumers.

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

Last Edited: Mon. Jul 13, 2020 - 11:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Best option is to buy from a reputable source!  Yes, a M328 will draw more power then the pico power version M328P.   Who knows what a china cloan will do?

Some solder fluxes (water soluble) will be conductive, so must be carefully cleaned after reflow, or leakage across pads will happen.  It does not take much leakage to raise your current consumption.

It takes very careful design and construction to get low micro current operation!

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

And it has an LED on D13 like most Arduinos

Did you say you removed this LED? You only mention removing the power LED....if not remove it.  Even though you set to output & set it low (to nearly zero volts), the LED could have some leakage (though I'd think it would be a few ua at most).   

This is really grasping at straws, but hey, what else do you have to lose?

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

The LED is connected to ground, so when the AVR pin is low, there cannot be any leakage.  Even if it was an open-drain setup, the leakage would be limited to the AVR input pin leakage, which is in the picoAmp range.

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

The LED is connected to ground, so when the AVR pin is low, there cannot be any leakage.  

That is what you'd hope and expect, but there can be some changeover leakage in the avr driver stage, so that it puts out a low, non-zero, low voltage (say for grins it were a sloppy 20mv), then a 10k leaky led, could draw a 2ua leakage, very low, and probably even that is extreme.  Note they specify only the low output sink current (which is typically what 99.99% of people need).

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

avrcandies wrote:

capacitor leakages?

+1

 

Peabody wrote:
The capacitors on Vcc remain.  But I think it's unlikely the two separate copies would leak in exactly the same way.

Quite the opposite - if you buy 2 at the same time, it is quite likely that they will have come from the same batch.

 

Capacitors do have to be carefully selected for low leakage; so it is certainly possible that these 2 new ones just used cheap capacitors - and they have higher leakage.

Or they just came from a "poorer" batch.

 

ki0bk wrote:
Best option is to buy from a reputable source! 

Absolutely!

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...
Last Edited: Tue. Jul 14, 2020 - 12:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I burned the "breadboard" version of the bootloader to one of the new Minis, which makes the chip use the 8MHz internal oscillator instead of the external resonator, then reflashed the sleep current test sketch.  It still drew 150uA.

 

So then I began removing everything from the PCB, testing again after each removal.  The last thing to go was the resonator.  So now with only the processor remaining on the board, I still get 150uA of sleep current.

 

I'm pretty satisfied with the explanation that something is wrong with these two chips.  I don't know if they are defective, or mis-marked, or what, but there appears to be nothing I can do to fix the problem.  While I guess I could go on to remove the processor from the board, I don't think that's going to give me any more information.  Meanwhile, I've ordered another bunch of Minis from a different source, and will see how they turn out.

 

I just hope the explanation isn't that Microchip has made a change they haven't told us about.  These chips appear to work fine except that they draw too much current in sleep mode.  The additional 150uA might also be there in active mode, but might not be noticeable.  But of course the sleep current would make a difference in battery life.  If anyone else does the Mini conversion to low power (removing the regulator and power LED), or sets up a breadboard Arduino with a PU part, you might want to try running my test sketch (in my first post) and see what you get for sleep current.  The datasheet is pretty clear that it should be in the ballpark of 1uA.

 

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

I guess it's possible that they are "grey market" chips - factory floor sweepings, or test fails, or suchlike ...

 

I guess I could go on to remove the processor from the board, I don't think that's going to give me any more information.  

It would tell you if there's some leakage in the PCB itself ...

 

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

floating pins. I see it has been said, but... update: never mind I see pins are all low

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

Last Edited: Wed. Jul 15, 2020 - 11:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I didn't see the comparator mentioned....how about:

 

When entering Idle mode, the Analog Comparator should be disabled if not used. When entering ADC Noise
Reduction mode, the Analog Comparator should be disabled. In other sleep modes, the Analog Comparator is
automatically disabled. However, if the Analog Comparator is set up to use the Internal Voltage Reference as
input, the Analog Comparator should be disabled in all sleep modes. Otherwise, the Internal Voltage Reference will
be enabled, independent of sleep mode. Refer to ”Analog Comparator” on page 239 for details on how to configure
the Analog Comparator.

 

ACSR:

When this bit is written logic one, the power to the Analog Comparator is switched off. This bit can be set at any
time to turn off the Analog Comparator. This will reduce power consumption in Active and Idle mode.

 

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

Last Edited: Thu. Jul 16, 2020 - 03:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I ordered another batch of Pro Minis from a different source, and they arrived today.  Unfortunately, they behave exactly like the other new Minis - they sleep at 150uA rather than the 1uA shown in the datasheet.

 

So I have a situation where the old Mini (date code 2018) operates properly and sleeps at 1uA, whereas all the new Minis (date code 2019) sleep at 150uA.  So it seems to me that either all the new Minis have counterfeit processors, or there has been a recent change in the 328P that's not reflected in the datasheet.

 

Does anyone from Atmel/Microchip participate here?  If not, is there any way I could contact someone at the company to officially report this problem and possibly find a solution?

 

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

Do you try turning off the comparator?  It is on by default (see #16)

 

Have you gone back to your working board to verify you still read 1 ua?...It would be a mess to find out something happened to your meter & you were chasing a ghost.  Go back and verify!

 

Also how much current do the stripped down boards (working and failing) draw when they are just looping or delaying prior to going to sleep...do those board currents even compare?  I'm wondering if the failing board is even going to sleep--- how much current change do you see between run mode and sleep mode?  You've never stated that.

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

Last Edited: Tue. Jul 21, 2020 - 07:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Late to the party but maybe something, here.

 

1. The fact that some chips were painted means that they have been somewhere else than straight from the factory to the distributor.

 

2. I saw no list of the fuses for the two sets of chips. Fuses are ONE big thing that could be a relic of a former life. Another could be pin damage (by excess voltage or current).

 

3. Are you certain that the clock frequencies are the same? That could lead do different current draws in normal operation. This is set by fuses, so there is another reason for a table of fuse settings.

 

4. In reset, all the pins are set to floating inputs. Thus, presence of external load resistances to Vcc or Gnd should have no bearing. Not so in sleep.

 

5. Which sleep is being used? Different sleeps enable or disable various clocks and peripheral modules. If the code is identical, then there should be no differece.

 

6. It sounds like some chips might have been true Atmel and newer ones from the Microchip fab. There may be some process differences. An important question is whether or not the higher current ones are actually in-spec or out of spec. If the newer ones have higher current but are still in spec, then there isn't much to be done.

 

Cheers

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

And don't discount leaky caps. I've been fixing some synthesizers recently which have had random dud ceramic caps. It's a warranty nightmare.

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

Again, buying cheap Chinese stuff, you're stuck with whatever they send you.

 

One of the key reasons they are cheap is because you get no support, no guarantees, no continuity of supply, etc.

 

You gets what you pays for

 

There is no such thing as a free lunch.

 

https://www.avrfreaks.net/commen...

 

Have you tried some genuine  Pro Minis ?

 

Peabody wrote:
is there any way I could contact someone at [Microchip] to officially report this problem and possibly find a solution?

You'd have to raise a support ticket - see: https://community.atmel.com/comm...

 

You'd really need to take (at least one of) the chips off the board to be sure that it isn't anything due to the board

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, we seem to be going over the same ground again and again.  The situation is that two new batches of Minis from different sources, using different parts, and with different markngs on the processor (but all 328P of course), all go into Power Down sleep at 150uA, which is two orders of magnitude higher than the datasheet spec.  But an older Mini sleeps at less than 1uA, which is within spec.  The old and new have in common the same board, the same bootloader, the same fuse settings, and the same test sketch.  The date code on the older part appears to be 2018, which matches when I bought it, and the date codes on the new parts are all 2019.

 

Since I removed *ALL* of the parts except the processor from one of the new Minis, and still got 150uA sleep current, we know it's not leaky capacitors or something similar.  When I raise Vcc from 3.3V to 5V, the sleep current rises to 330uA, which is not a linear change.  The problem is clearly in the processor, not the board or the other parts. 

 

It seems to me there are two possibiities that make any sense at all.  The first is that all of the new Minis have counterfeit processors on them.  The second is that there has been a recent change to the 328P by Microchip that is not documented but which causes this problem.  I guess I could order a new 328P from Digikey, which would presumably be genuine, but I can't specify a date code on the part Digikey sends me.  If they send me a 2018 code, and it works fine, that tells me nothing I don't already know.

 

Even if there has been a silicon change that caused this, I keep hoping there is a software solution that would fix it - something that I havent turned off that now needs to be turned off.  But I haven't found anything like that in searches, and apparently nobody here knows of anything like that.

 

I guess I will try to open a ticket, but I'm just a hobbiest, and they aren't going to take me seriously.  I'd be happy to send them one of the Minis that's misbehaving if that would help.  But for the moment I have to conclude that using the Pro Mini as a very low sleep current option for battery powered projects just doesn't work anymore. 

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

Peabody wrote:
Well, we seem to be going over the same ground again and again

indeed

 

two new batches of Minis from different sources

Well, from differenent resellers - how do you know they're actually from different sources (ie, manufacturers)?

 

The old and new have in common the same board

Again, how do you know that?

 

It might look similar, but ...

 

I removed *ALL* of the parts except the processor from one of the new Minis, and still got 150uA sleep current, we know it's not leaky capacitors or something similar

Again, there is still the question of the PCB itself.

 

The problem is clearly in the processor, not the board

Hmmm - I think that remains unproven ...

 

It seems to me there are two possibiities that make any sense at all.  The first is that all of the new Minis have counterfeit processors on them.  The second is that there has been a recent change to the 328P by Microchip

A 3rd is that the chips are somehow being damaged during manufacture or handling.

 

I was involved in a project like this recently. I was moved on before we reached a definite conclusion, but there was certainly the possibility that the chip was getting damaged in manufacture or factory handling.

 

But for the moment I have to conclude that using the Pro Mini as a very low sleep current option for battery powered projects just doesn't work anymore. 

You mean, using cheap Chinese clone  Pro Minis from ebay - so, again, what about trying a "genuine" one from a reputable supplier?

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...
Last Edited: Tue. Jul 21, 2020 - 02:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What are your fuses set to?

#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

Try this sketch and see if it helps:

 

#include <avr/sleep.h>
#include <avr/wdt.h>
int i;

void setup(){

  for (i = 0; i < 20; i++) {          // all pins to one rail or the other
    pinMode(i,OUTPUT);
    digitalWrite(i,LOW);
  }
  ADCSRA = 0;                         // disable ADC for power saving
  wdt_disable();                      // disable WDT for power saving
  PRR = 0xEF;                         // power down all modules
  set_sleep_mode (SLEEP_MODE_PWR_DOWN); // Deep sleep
  sleep_enable();
  sleep_bod_disable();                // disable brownout detector during sleep
  sleep_cpu();                        // now go to sleep

}

void loop(){
}

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Once again, are you sure the comparator is off?  See #16 & ensure that it is explicitly turned off your code.

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

Last Edited: Tue. Jul 21, 2020 - 04:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

Try this sketch and see if it helps:

 

#include <avr/sleep.h>
#include <avr/wdt.h>
int i;

void setup(){

  for (i = 0; i < 20; i++) {          // all pins to one rail or the other
    pinMode(i,OUTPUT);
    digitalWrite(i,LOW);
  }
  ADCSRA = 0;                         // disable ADC for power saving
  wdt_disable();                      // disable WDT for power saving
  PRR = 0xEF;                         // power down all modules
  set_sleep_mode (SLEEP_MODE_PWR_DOWN); // Deep sleep
  sleep_enable();
  sleep_bod_disable();                // disable brownout detector during sleep
  sleep_cpu();                        // now go to sleep

}

void loop(){
}

 

Thanks very much.  Your sketch also produces sleep current of 150uA.  And I tried adding specific code to disable the comparator, as suggested elsewhere, but that had no effect.

 

 

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

And what happens if you ditch Arduino and just use plain C or Asm?

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

Could the reset switch be leaky?  Especially if it uses a cheapy rubber dome instead of a metal one..  I'vs seen rubber dome keypad switches that are not infinite in the open/off position, but go very low (as desired) when pressed.

 

What other parts are left besides the micro? Probably none; maybe you added ceramic caps back for run safety.

 

 

 

 

 

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

Brian Fairchild wrote:

What are your fuses set to?

+1

 

Four legs good, two legs bad, three legs stable.

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

Probably they are different chips with fake markings. For example, you know all those mega128 that you can buy from Aliexpress or Ebay for less than $1?

I have a few. If you look carefully at the markings, it's clearly visible there was something different below that was crudely erased and new markings were applied. It's common practice. They do work as regular mega128 though.

 

Anyway, yeah, maybe it's a bad batch that should have been destroyed but instead found it's way to shady dealers.

 

Last Edited: Wed. Jul 22, 2020 - 08:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps microchip actually started to produce a K version or perhaps L (where full swing osc works) , and we know that that "new" process  leaks more than Atmels version.

 

 

Add:

But perhaps only sold in asia!

Last Edited: Wed. Jul 22, 2020 - 09:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One way to find out is to buy a "real" 328P and replace it with one that use 150uA

 

Other thing perhaps the PCB's aren't the same?

like how Vcc and AVcc connected?

what about Aref ?

how is reset done?

are there a leaky regulator?

 

Are we sure that NO inputs are floating? (and if pulled low that the pullup resistor is disabled)

If you use a boot loader make sure that RX isn't floating when you do this. 

 

   

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

I think it is better to read the entire discussion before posting rather than posting same things many times! sad

Slow and Steady!

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

sorry if there was some repeats.

 

But one thing still missing is the fuse settings !

 

One thing it could be is that BOD is enabled (it's a fuse).

(You can manually disable it)

 

 

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

I didn't mean you. (However, two of your questions were repeated ;-) )

I'm talking to all members.

Slow and Steady!

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

pajuhesh80 wrote:

I think it is better to read the entire discussion before posting rather than posting same things many times! 

 

And yet you aren't following you own advice. What are your fuses set to?

#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:

And yet you aren't following you own advice. What are your fuses set to?

Me? Why? I didn't post any repeated thing in this thread at all! surprise

And currently I'm not working on any AVR projects. So my fuses are set to nothing! wink

 

If you asked it from OP, he said that he used same program and same fuses for both boards.

Slow and Steady!

Last Edited: Wed. Jul 22, 2020 - 03:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pajuhesh80 wrote:

Me? Why? I didn't post any repeated thing in this thread at all! 

 

Apologies.

 

pajuhesh80 wrote:

If you asked it from OP, he said that he used same program and same fuses for both boards.

 

Yeah. But he still hasn't said what the fuse setting is.

#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:
Yeah. But he still hasn't said what the fuse setting is.

Most likely as OP is working with Arduino IDE, they don't know, so standard fuses for any 328 based arduino (nano)

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

ki0bk wrote:

Brian Fairchild wrote:

Yeah. But he still hasn't said what the fuse setting is.

Most likely as OP is working with Arduino IDE, they don't know, so standard fuses for any 328 based arduino (nano)

 

But the OP said...

 

Quote:

Since I removed *ALL* of the parts except the processor from one of the new Minis, and still got 150uA sleep current

 

...which with standard fuses on a mini would mean the processor would not run as it's expecting a crystal/resonator.

#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:
...which with standard fuses on a mini would mean the processor would not run as it's expecting a crystal/resonator.

Which could explain the "reset" current?  IIRC that is surprisingly high.

But that means that there IS a clock source, right?  Making my head hurt.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Thu. Jul 23, 2020 - 01:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps OP could post some high-res pictures of both PCBs?

 

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


I just had a look at the datasheet that have revision K errata. (the one without full swing). So if the new chips is revision K microchip really have some problems other than OSC 

 

At least it has an other debugWire ID number so you can see if it's a rev. K

(and as said before perhaps it's released i Asia)

 

 

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


Here we go again...

 

 

 

Rev K was NEVER released. Why on earth would a global company like Microchip risk releasing it in just one region knowing that it would find it's way into the global supply chain? Answer, they didn't.

#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

We still need the OP to clarify EXACTLY what was left on the board and what changes they made to the fuses to accommodate the fact that with the crystal/resonator removed the chip wouldn't run.

#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

OP has not been heard from since #27, time to let this die until heard from again.

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

I hope you a right, the info I posted is from the current datasheet that is from 2018.

 

And why they should do it, they have have a cheaper fab that can produce them for about 1/2 price.

The 328p and 328pb should cost about the same if from same line but a 328p is about $1.8 and a 328pb $1.0 and we know that the 328pb is like a K version.

 

And over from here until we hear for OP or microchip ;)

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

ki0bk wrote:

OP has not been heard from since #27, time to let this die until heard from again.

 

 

I apologize for my absence.

 

So hopefully to clarify things, the fuse settings on all the parts, both good and bad are FF, DA and FD.  That's low, high and extended.  and those are the stock fuses in the IDE for a 3.3V 8Mhz Pro Mini.

 

Before removing all the parts from one board, I reprogrammed it as a "Atmega 328 on a breadboard (8mHz internal clock)".  You have to download a hardware file for that, but it seems to work fine, and has its own bootloader.  That has fuses of E2, DA and FD.  Then I also reflashed the test sketch in case that mattered.  Then I removed everything from the board, including the reset button, added back capacitors to Vcc that I know are good, and powered up.  It went through the boot process just like before, then went to sleep - at 150uA.  Since all the PC boards are identical, and since I now know that none of the other parts on the board were causing the problem, and since all five bad ones sleep at 150uA, not 170, or 95, but 150, the only answer I have at this point is that it's the processor that's causing the high sleep current.

 

The only thing I can conclude from the markings is that the good part has a 2018 date code, and all the bad ones are 2019.  I have communicated with Digikey and they confirm they have stock with dates as late as March, 2020.  I have also sent email to Kevin Darrah (no response so far) because he is known for his micropower stuff, and I thought he might have chips in stock with recent date codes, and could test to see how deeply they sleep.

 

It seems to me that what needs to happen is replacing the processor on one of the bad Minis with a known genuine part with a date code at least as new as the bad chip date codes, but what the hell - why not March 2020 since they're available.  If the Mini then works properly and sleeps at 1uA, then either the bad ones are fakes, or the bad ones may even be genuiine, but at least I have a source of good chips.  If the replacement chip also sleeps at 150uA, then Microchip has really screwed things up.  I have not yet attempted to open a ticket with Microchip, and probably won't do that unless a known genuine chip doesn't sleep right.

 

The problem I have is that I'm an old guy with shaky hands, and I have a soldering iron but no other rework stuff.  And frankly, I'm not sure I want to spend lots more bucks getting to the bottom of this.  So far I'm out $23 with no sleepable Minis to show for that investment.  Replacement processors from Digikey for the four remaining bad parts would be another $14 delivered.  ChipQwik would be another $17, or a hot air gun even more.

 

So I don't know what I'm going to do.

 

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

I have tested a "modified" Arduino Pro Mini clone bought 3 years ago. The sleeping current consumption is about 2.5µA.

I am deeply disappointed.

 

The truth is more important than the facts.

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

I heard back from Kevin Darrah, and have sent him one of the bad ones from the second batch to experiment with, and he may make a video on it.   He seems to feel that these are all counterfeits, but I'm not so sure.  Anyway, I've suggested that it would make a good before-and-after video if he switched out the bad chip with a known good one from Digikey, but don't know if he will do that.

 

I think for the moment I'm pretty much done with this.  I don't really need anything else from Digikey at the moment, and don't want to pay shipping just for this.  But if a need develops for other Digikey stuff, I'll throw in a couple 328Ps and take my chances with doing the replacement.

 

Meanwhile, if anyone else here already has a Mini with a recent date code, I hope you'll consider modifying it for low current and testing it.

 

Thanks for everyone's comments and suggestions.  I hope at some point we'll come to a definitive answer.

 

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

We're talking 'Power Down' mode here? Yes?

 

Has anyone looked to see EXACTLY what the generated code from the OP's sketch is?

#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

I wonder if those parts might be from green logic or whatever that AVR clone company is called.

 

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

That would surprise me they have there own version that in many ways are better.

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

I know almost nothing about chip manufacturing. Must all deficient chips unconditionally invariably be destroyed, or is it possible to steal semi-defective devices?

The truth is more important than the facts.

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

I don't know how it's with microchip, but I know that Atmel didn't really test on die level it was cheaper to put them in a house, so they could be tested in a (cheaper) less clean environment.

So what happen with those that don't pass is a good question.

I remember that we had a place here in DK that in the 80's sold cheap ti TTL chips that only had a code on the bottom side (very very cheap and no warranty).

 

But since all these boards behave the same way I don't think it's rejects.

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

Brian Fairchild wrote:

We're talking 'Power Down' mode here? Yes?

 

Has anyone looked to see EXACTLY what the generated code from the OP's sketch is?

 

Yes.

 

My test sketch is in my first post.  You are welcome to do a test compile for the 3.3V Pro Mini, and examine whatever the IDE produces.  But in the end, the code works fine on the older Mini, but not on the newer ones, and whatever code is produced is the same for all.  So I don't think that exercise would tell you anything.

 

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

I reread this (#49), and I'm still not sure about floating inputs!

 

As asked in #33 what about the RX pin, you say that you have everything taken of the board.

Are you 100% sure that the bootloader disable the USART ? (To be clear if the RX bit is enabled in the USART the RX pin is an input regardless of the DDR register for pin.)

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

OP indicated he flashed the same bootloader, same fuses, and same application code to both PCBs...so USART will be configured the same between them.

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

Peabody wrote:

You are welcome to do a test compile for the 3.3V Pro Mini,...

 

That assumes that...

 

a) I have the Arduino toolchain installed

b) I can remember where to find, ideally the generated .lst file or likely, the .hex file and

c) if it's .hex that I have a way of disassembling it.

#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

Peabody wrote:

The new ones have these markings:

 

Atmel
MEGA328P
U-TW
35473D
1947X5N

and
1936S2P

 

 

The old one is:

 

Atmel
MEGA328P
U-KR
35473D
1829R5G

 

If those markings are on genuine chips then both your old and new chips have the same die and revision in them, 35473 rev D

 

The only difference is then the country of origin, KR vs TW (Korea/Taiwan).

#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

Yes but a floating input pin (without pull up) will behave different on different chips, and that is ok (it's outside spec) as long it's within spec of the datasheet  for normal use.

 

On some chips a floating pin go close to Gnd or Vcc (I guess leak in protection diodes), and it will be fine. On others it will sit close to Vcc/2 and the transistors will sit in the linear range and there will be a leak current.   

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

Brian Fairchild wrote:
If those markings are on genuine chips

 

It's possible to check if they are genuine, the 328P keeps some data internally that should match the markings.

 

Discussion here:  https://www.avrfreaks.net/forum/undocumented-signature-row-contents

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

Why not write a 12 line asm program...then there is no doubt all ports are output low, nothing is floating, all blocks use prr to power down, etc

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

avrcandies wrote:

Why not write a 12 line asm program...then there is no doubt all ports are output low, nothing is floating, all blocks use prr to power down, etc

 

Why does it matter if it's 12 lines or 1200 lines?

 

OP indicated the SAME bootloader, SAME fuses, and SAME code were on both devices, yet one pulled more current than the other.

 

 

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

OP indicated the SAME bootloader, SAME fuses, and SAME code were on both devices, yet one pulled more current than the other.

You seem to not be paying attention...if a line is left floating

 

on one chip there may be no effect

on another chip it may cause a large current draw 

 

   ...why...because it is floating, as no inputs on cmos logic should be allowed to float.... . However, when switching from one state to another, the input crosses the threshold region, causing the N-channel and the Pchannel to turn on simultaneously, generating a current path between VCC and GND. This current surge can be damaging, depending on the length of time that the input is in the threshold region (0.8 to 2 V). ...For example, if an 18-bit transceiver has 36 I/O pins floating at the threshold, the current from VCC can be as high as 150 mA to 200 mA. This is approximately 1 W of power consumed by the device

 

Now you are in the winner's circle!  The prize patrol will accept your credit card.

 

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

 In case it matters, the new ones both had daubs of white paint covering the markings. 

I only order uC's in quantities of 10's not 10,000's, (or more).

But I've never seen factory new chips that were altered, (painted!).

That just sounds very suspicious.

 

It would be great if Peabody did open a support ticket with MC, as they can easily Xray the chip to see if it is their chip or a knock-off.

If it is a true MC part, then the question remains as to the current draw, if it is a counterfeit part then all bets are off, it doesn't have to follow the detailed spec's of the data sheet.

 

I thought I saw it mentioned above, but on a quick read through again I missed it.

I wondered the test set up and instrument used to measure the sleep currents.

I'd love to see a picture of the setup.

 

Although I have several DMMs, I only have one Fluke, (Thank you MicroCarl!), and I don't recall it's low range current capabilities.

I routinely measure mA's, not 1.x uA's or pA's ...

Hence my interest in how one does this accurately and reproducibly.

 

JC

  

 

 

 

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

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

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

I routinely measure mA's, not 1.x uA's or pA's ...

I asked about this early in the thread, run-of-the-mill meters could be off a good fraction of a milliamp  (10's or 100's of microamps).. At least go back to the "working" chip to ensure  its not a matter of  0.1 mA (100 uA) drift.

 

I've got some pretty good 6.5 digit meters, but never really use 'em, just like my Fluke 189 instead.  I picked up a Yokogawa calibrator for a song (like $150), I should blow off the dust & get the calibrator calibrated!   Then go around and ensure everything is nulled out.

https://www.ebay.com/itm/YOKOGAWA-2552-12-1200V-25mA-DC-Standard-Source/143639293976?hash=item217191b018:g:EaIAAOSwB0he8qp4

 

 

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

avrcandies wrote:

Now you are in the winner's circle!  The prize patrol will accept your credit card.

 

 

Woah, burn...you really got me there.

 

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

DocJC wrote:

 

I thought I saw it mentioned above, but on a quick read through again I missed it.

 

I wondered the test set up and instrument used to measure the sleep currents.

I'd love to see a picture of the setup.

 

Although I have several DMMs, I only have one Fluke, (Thank you MicroCarl!), and I don't recall it's low range current capabilities.

I routinely measure mA's, not 1.x uA's or pA's ...

Hence my interest in how one does this accurately and reproduciblly.

 

JC

 

I don't know what this "DMM " rubbish is you speak of.  Attached is a picture of my test instrument.  This is shown reading the current drawn by the bad Mini after it has gone to sleep,  set to the 0.5mA scale, or 500uA.  Not shown is the 3.3V power supply.  The good mini reads essentially zero (you can just barely see the needle move above zero) on the 50uA scale.

 

 

Attachment(s): 

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

I think grandpa wants his multimeter back! Oops! He thinks anything other than an AVO8 is trash :)

Regardless of whether you use a digital or analog multimeter, there’s traps when measuring low currents. Ron gave some links in#68. Whether the burden voltage is an issue in this case is debatable - it can cause weird results.

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

 

Oh boy, you can certainly have a lot of meter troubles...since there is no analog circuitry to amplify the current, you probably have a very high ohm shunt (terrible as a low impedance AVR power supply connection).

Do you know what your burden voltage (voltage loss) is?   What voltage do you measure at the AVR when your current meter is installed to measure current?

 

Try running your current through a 100 ohm resistor and good size cap on the AVR side & just measure the voltage drop across that.  A  few microamps will then only generate a few hundred microvolts drop.  The 100 ohms isn't  the "best" connection, but tolerable.    You can set your meter to the current range & use another meter to ohm it out....see what it's shunt resistance is...it could be a few 1000 ohms.

 

One thing going for the analog gauge, is it does a nice job of averaging.   You definitely need to ditch it & at least get a true rms meter for general work.  True RMS is the ONLY way to go these days.  Don't buy a non-true rms meter.   

 

I took an old junko FREE harbor freight meter 

on the 200uA scale, it reads as a 1000 ohm shunt.....kinda blah

my fluke 197 reads 100 ohms on the ua scale...much better (well, 10 times better).

 

 

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

Last Edited: Sat. Jul 25, 2020 - 01:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Whether the burden voltage is an issue in this case is debatable - it can cause weird results.
My first thought.

 

avrcandies wrote:
Try running your current through a 100 ohm resistor and good size cap on the AVR side & just measure the voltage drop across that.

Or, bypass the meter with a hard short, then power-up the AVR.  Let it sit for a few seconds, long enough to be certain that the bootloader has timed out and the app has started and gone to sleep, then remove the hard short across the meter.

"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

Well I was kinda pulling your leg.  I also have a digital meter.  It reads 0 mA on the good Mini, and .15mA on the bad one.  So, the same reading on both meters.  And actually, I find the analog meter to be useful in some situations.  Anyway, this isn't a meter problem.  The difference between good and bad is two orders of magnitude.  A precise measurement isn't the issue.  And by the way, that analog meter is a genuine Soltec, not some cheap imitation.  :-)

 

 

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

The issue >>may<< be that with the burden voltage of any meter, analogue or digital, can cause the AVR to run out-of-spec while coming out of reset and running code before going to sleep.  Out-of-spec means all bets are off.  As in, no guarantees.  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.

 

Perform a proper test, as suggested in #74.  I don't >>expect<< to find any change, but still you must rule this out.

 

 

"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

Speaking of picking things up from Digikey, they sell quite a variety of current sensor ICs with shunt resistance in the milli (and micro I think!) ohm range.  Might take a bit of support stuff to make them behave (or buy a development kit) but if you're seriously worried about microamps and nanoamps you should get the right tools to measure them.  IMHO.  If $23 is important, perhaps you'd do better spending the money on a nice dinner with a cheerful friend.  S.

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

There's no point talking about the measuring equipment. We are not trying to distinguish between say 0.15µA and 0.16µA here. We are talking about much bigger differences.
 

The truth is more important than the facts.

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

Yes, but read post #76

Four legs good, two legs bad, three legs stable.

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

poftamunk wrote:
There's no point talking about the measuring equipment

You've missed the point!

 

The point is that the meter's series resistance (whence "burden voltage") might be interfering with proper operation of the AVR.

 

Effectively, the power supply has a too-high impedance.

 

In particular, the high resistance might be preventing it from starting correctly - leaving it in an unexpected state, which draws the excess current.

 

 

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps have a BIG cap on the power and let it live of that while at sleep. Then measure the voltage every ? 10 min. (for a short time if it's a bad meter). If the voltage drop from 5V to 4V take the same time it's a current measuring problem. 

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

sparrow2 wrote:
Perhaps have a BIG cap on the power and let it live of that while at sleep

Good idea.

 

Would have to be sure it's a low-leakage cap, though ...

 

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

poftamunk wrote:
There's no point talking about the measuring equipment

You've missed the point! The point is that the meter's series resistance (whence "burden voltage") might be interfering with proper operation of the AVR.

 

The manual for the meter is online. The answer is 800 ohms.

 

 

[EDIT]

 

To be accurate it's 736 Ohms.

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."

Last Edited: Tue. Jul 28, 2020 - 11:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And BTW, the burden resistance on the 50uA range will be 5k!

#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: 1

poftamunk wrote:

There's no point talking about the measuring equipment...

 

I beg to differ...

 

Brian Fairchild wrote:

To be accurate it's 736 Ohms.

 

And why does this matter.

 

You have a 736 Ohm resistor that is in series with your 3.3V supply.

 

On start up your chip, on 3.3V and 8MHz, will want to draw around 3mA. Which I make a drop of (0.003 x 800) = 2.4V. That's 2.4V across the meter. So your chip is left with 0.9V. So it won't even get to running your power saving code.

#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:
To be accurate it's 736 Ohms

which is rather high for a power supply impedance.

 

@ Peabody : What current does the AVR take at start up?  At that current, what will its Vdd voltage be?

 

EDIT: Brian beat me to it on that!

 

In #74, joeymorin wrote:
bypass the meter with a hard short, then power-up the AVR.  Let it sit for a few seconds, long enough to be certain that the bootloader has timed out and the app has started and gone to sleep, then remove the hard short across the meter.

Do that!

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...
Last Edited: Tue. Jul 28, 2020 - 12:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ohm's law is hard to argue with!

 

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

Ohm's law is hard to argue with!

I bet some of those protesters in Melbourne would try anyway.....they have rights you know, they may not agree with Ohms law and therefore they will not comply with it.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

 

Perhaps it's different "real" chips I was looking in different change notes and found this (for all mega48 88 168 328)

Atmel 2015

 

 And this from Microchip this year

 

 

So at some point then production have been moved to Colorado FAB5 

or perhaps the high current are SMIC chips

 

Add

Or is Microchip Colorado FAB5, an old Atmel FAB ? 

Last Edited: Wed. Jul 29, 2020 - 10:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

...So at some point then production have been moved to Colorado FAB5...

 

I think that at the moment you start using chips so far out of spec then all bets are off and anything written in the datasheet is meaningless.

#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:
the moment you start using chips so far out of spec then all bets are off

Absolutely - you are into undefined behaviour !

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would like to add another bit of evidence that may support my belief that all the 328P stock now has the high sleep current.

 

There is a recent video by Ralph Bacon which deals with using a DS3231 alarm to wake up a 328P-PU DIP chip:

 

https://www.youtube.com/watch?v=-dW4XsBo3Mk

 

Of course he is concerned with sleep current here, and in an effort to determine what's drawing current, at 6:10 into the video he pushes the button that makes the processor set the alarm, then go to sleep, and then he disconnects the power from the DS3231.  At that point, the 328P sleep current drops to:

 

 

150uA.

 

 

Now of course I don't know his fuses or bootloader or whether he has everything turned off, but he has done all of this before many times, so I assume he's doing it right.  In fact he says he has demonstrated before that the 328P will sleep at far lower currents.  His explanation of the 150mA - the I2C lines - I believe is wrong because he has disconnected the power to the module.

 

I think it's possible that it's not just a coincidence that the 150uA he is seeing is exaclty the same as I am seeing in the AU parts.  I have written to him to ask about the date code on the PU, and if he can repeat his test using an older PU part.  I also asked about his source for the PU chips.

 

Meanwhile, Kevin Darrah reports that he has ordered new (i.e. - 2020) AU parts from Digikey, and will test them on arrival.  For those not familiar with him, here's his video from a while ago about sleep current:

 

https://www.youtube.com/watch?v=urLSDi7SD8M

 

Film at 11:00, as they used to say.

 

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

So have you done the test described in #74 (and mentioned in#86) yet ?

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, as I mentioned in #75, the analog meter was kind of a joke, and I also have a digital meter that reads the same current.  But apparently nobody paid any attention to that, preferring to give me grief about the analog meter.  But yes, I tried shorting around each meter until sleep was underway, and that made no difference.  But it doesn't matter.  Kevin will be testing one of my Minis, as well as a new 328P from Digikey, using his extensive gear.  And I think those tests will pretty much tell the story.

 

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

In both those videos I can see glaring errors/assumptions. Be careful how much creedence you give these. 

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

DMM have burden voltages, too.  Generally higher for lower current ranges.  What's yours on the range you are using?

"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

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.

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

The promised value is below 0.2µA.

 

 

The truth is more important than the facts.

Last Edited: Fri. Jul 31, 2020 - 04:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

poftamunk wrote:

The promised value is below 0.2µA.

 

I don't think anyone disputes that.

#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


The whole issue is easily solved.

 

1) Take 1 genuine 328P with the same die revision as the OP (35473D). BTW, I know it's genuine because I buy directly from Microchip.

 

2) Put it in the minimal circuit possible...

 

 

3) Set the fuses...

 

 

4) Program the 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");

 

5) Measure the result...

 

 

6) Verify the test setup and methodology with different code...

 

    while (1) {


      }

 

7) Show the verification...

 

 

 

Happy to have any observations regarding my tests.

#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

Now, does anyone know if the OPs code falls foul of this note in CVAVR's help file regarding sleep functions...

 

Peabody wrote:

 

#include <avr/sleep.h>
#include <avr/wdt.h>
int i;

void setup(){

  for (i = 0; i < 20; i++) {          // all pins to one rail or the other
    pinMode(i,OUTPUT);
    digitalWrite(i,LOW);
  }
  ADCSRA = 0;                         // disable ADC for power saving
  wdt_disable();                      // disable WDT for power saving
  set_sleep_mode (SLEEP_MODE_PWR_DOWN); // Deep sleep
  sleep_enable();
  sleep_bod_disable();                // disable brownout detector during sleep
  sleep_cpu();                        // now go to sleep

}

void loop(){
}

 

 

Quote:

Note: There are specific situations where the power management functions can’t be used because of the timing limitations.

For example the ATmega168P chip has a feature which is not available in ATmega168: Brown-Out Detection disable during sleep.

If we wish to use this feature, we need to enter in sleep mode in maximum 4 clocks after the BODS bit is set in the MCUCR register.

But calling and executing the powersave function requires a longer time than than this, so this example code will not function correctly:

#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: 1

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: 1

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just wanted to report that Kevin Darrah has tested the Minis I sent him, and he gets the same results I did.  Well, he got 138uA at 3V, which I think is the same ballpark as 150uA at 3.3V.

 

However, he has also tested the new 328P-AU he received from Digikey, with a date code of 2002, and it sleeps normally at under 1uA.  I believe he is going to post s video on this subject.

 

Kevin has tentatively concluded that all the parts I sent him, and by implication the one sleemanj has that behaves the same way, are counterfeits.  But he suggests that one other distinction that may need to be looked at is the country code.  All of my bad ones are marked either KR or TW, but the good one Kevin got from Digikey is marked TH. SleemanJ's bad one is also TW.  But to the contrary, my good chip from 2018 is also KR.  So if the issue is the fab location it still only applies to about mid-2019 and later.

 

Brian, you said your DIP chip was a 328PU, but did you really mean 328P-PU?   If so, could you post all the markings?  We have the example of Ralph Bacon's 328P-PU, markings unknown, sleeping at 150uA, so it's possible the PU is involved.  Your 1924 date code is a little earlier than the earliest bad chip seen up to now (1933), but I agree it's pretty close.  But I'd like to know the country code and the revision.

 

I'm still hoping that Kevin will raise this issue with Microchip since he is already known to them.  Maybe it's hoping for too much, but I'd just like to have someone from Microchip tell us that the chips I sent to Kevin are indeed not genuine parts, if that's the case.  So if Kevin doesn't want to mess with that, I may give it a try.  I think it's still possible that all these chips are genuine, and even if it was not deliberate, runs of bad parts took place for a while in 2019 in Korea and Taiwan, and may still be taking place.  The other reason for contacting Microchip is to try to find a software solution if the parts are genuine.  There may be a bit we could flip in some register that would turn off whatever is still running, and that would effectively fix the problem.

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

Over the years, there have been problems with "discarded" out-of-spec chips being pilfered from trash bins in factories and then sold. Not Microchip, specifically - don't remember who or where it was In many cases, they had date and country markings. I would have expected that the final production sites would now be more aware of that possibility, but maybe not. Who knows? Of course, we don't even know that to be the actual problem, just one of many possibilities. 

 

And, if they were bought through some place like eBay, the final seller might not even have documentation on the full chain of possession. Personally, that is why I stick to "official" distribution channels.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

The "best" example of junk chips were the ones that contained a bit of copper inside the plastic mold and no micro, from memory there were several reels of fake AVRs.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

IIRC there is a blog post on Sparkfun about a pile of fakes that they ended up with.

#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



Over the years, there have been problems with "discarded" out-of-spec chips being pilfered from trash bins in factories and then sold.

remember

 

 

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:

Brian, you said your DIP chip was a 328PU, but did you really mean 328P-PU?   If so, could you post all the markings?  We have the example of Ralph Bacon's 328P-PU, markings unknown, sleeping at 150uA, so it's possible the PU is involved.  Your 1924 date code is a little earlier than the earliest bad chip seen up to now (1933), but I agree it's pretty close.  But I'd like to know the country code and the revision.

 

Full markings...

 

Top side...

 

Atmel

35473D

ATMEGA328P U

1924GC8

 

Moulded into underside...

 

Thailand

K2

 

#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

I wonder if country code, or pedantically 'Country of Origin', is a red herring? Plenty of manufacturers make the silicon in one location and package it in another.

 

This whole issue is definitely an 'over to Microchip' question.

#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

The 1N4148 diodes are a bit rich by today's standards........

The 75 7400 series ics for $1.98 might be a good deal. See who can make the best computer from them.

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

I doubt Microchip will pay much attention until the problem has been demonstrated on a bare chip with the minimum recommended external hardware. So far, attempts to encourage the OP to remove the PCB from the equation seem to have been unsuccessful, and have instead been met with hand waving and "obviously the board isn't the problem". Although, since this thread has dragged on for nearly three whole pages, I may have missed something.

Even so, errors in board assembly e.g. out-of-spec reflow profile could leave a perfectly good AVR damaged. Until the problem can be demonstrated with devices straight off the reel, or at least devices assembled using verifiably in-spec procedures, the conclusions put forth by the OP will remain speculative.

 

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: Wed. Aug 12, 2020 - 05:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kevin Darrah has posted his video:

 

https://youtu.be/PlGycKwnsSw

 

 

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

Brian, thanks for the markings information.  Your PU chip seems to be in the date range of those that have been bad, but the fab code is Thailand, and so far no bad AU chips have been found with the TH marking.  Anyway it's another datapoint.

 

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

Kevin Darrah sent the suspect chip to a company called Sensible Micro, which has lots of experience testing for bogus chips.  They decapped both the bad chip and a known good chip and compared them.  Their report is included in Kevin's followup video:

 

https://www.youtube.com/watch?v=o0rEzcKYzGw

 

Their conclusion is that the part is "suspect counterfeit".  It contains the logo "Aries" instead of "Atmel", and there are other differences.  So unless Microchip engaged someone else to make chips for them, it looks like this is indeed a counterfeit.

 

The bad news is that this means the entire "clone" market may now be infected with bogus processors, with no practical way to tell the difference.  I don't know whether Kevin plans to refer this to Microchip, but if anyone here has a good contact there, you might refer them to Kevin's videos.  One thing that would be nice to have is a test sketch of some kind that works one wsy on a good chip, but another way on a bad one.  Microchip might be able to provide something like that.  Removing regulators and LEDs to test for sleep current isn't practical for most hobbyists.

 

I want to thank everyone here for their comments and suggestions.  I just wish the outcome was more positive.

 

 

Last Edited: Mon. Sep 14, 2020 - 01:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Peabody wrote:
One thing that would be nice to have is a test sketch of some kind that works one wsy on a good chip, but another way on a bad one

Haven't viewed the whole video yet, but it does have some "test code" posted in the description - does that meet this requirement?

 

EDIT

 

Have now viewed both - and he does show the code which is used on both chips.

 

He does also eliminate the board itself - by moving the chip onto one of his own "known good" boards.

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...
Last Edited: Mon. Sep 14, 2020 - 10:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The interesting it in the video (IMHO) actually starts around: https://youtu.be/o0rEzcKYzGw?t=424 where we finally get to see the dies uncovered.

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

How do they compare to those Chinese AVR clones ... ?

 

https://www.avrfreaks.net/forum/forbiden-tech-china-has-arrived

 

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...
Last Edited: Mon. Sep 14, 2020 - 04:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


I can't quite make out what the logo says:

 

 

Does that say '5G'?

 

And 'Xino Bao'?

 

Just not clear enough to be sure...

"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

I wonder what that cost to have that done?

 

Jim

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Kevin provides what looks to be a good test sketch to differentiate between good and bad chips without having to desolder stuff.  Bad chips are mostly FFs past the first line.

 

https://gist.github.com/krdarrah/6e6cb94c1df015e8e9f910ae5cf85299

 

Real Digikey 2020

1E BA 95 FF F C6 0 26

FF 9 FF 17 FF FF 57 39

39 31 36 31 FF 1 29 1D

17 5 12 9 13 9 FF FF

 

Fake Ebay  2019

1E B8 95 FF F FF FF 26

FF FF FF FF FF FF 5D FF

FF FF FF 0 FF FF FF FF

FF FF FF FF FF FF FF FF

 

Older Pro Mini with real looking chip 2015

1E 96 95 FF F 9A FF 26

FF A FF 17 FF FF 58 35

32 31 38 36 FF F A 13

17 1 12 6 13 6 FF FF

 

Real Digikey 2016

1E 87 95 FF F D0 FF 26

FF A FF 17 FF FF 58 36

30 30 33 34 FF B 21 10

17 1 12 6 13 6 FF FF

 

Another Fake looking ProMini 2019

1E CF 95 FF F FF FF 26

FF FF FF FF FF FF 58 FF

FF FF FF 0 FF FF FF FF

FF FF FF FF FF FF FF FF

 

Mine look the same:

 

last bad Pro Mini clone - 2019 date code
1E    BE    95    FF    F    FF    FF    26    
FF    FF    FF    FF    FF    FF    58    FF    
FF    FF    FF    FF    FF    FF    FF    FF    
FF    FF    FF    FF    FF    FF    FF    FF    

 

good Pro Mini clone - 2015 date code
1E    A2    95    FF    F    B8    FF    26    
FF    9    FF    17    FF    FF    57    35    
37    34    39    33    FF    7    18    2    
17    1    12    6    13    6    FF    FF    

 

good Nano clone - 2018 date code
1E    A8    95    FF    F    C6    0    26    
FF    8    FF    17    FF    FF    57    38    
38    35    38    39    FF    9    19    B    
17    3    12    9    13    9    FF    FF    

 

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

This was the code used in the video:

 

https://github.com/krdarrah/lowP...

 

 

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

This was the code used in the video:

 

https://github.com/krdarrah/lowP...

 

 

 

I think that's the code he used to test the actual sleep current.  The new code tries to identify a counterfeit chip without having to remove regulators and LEDs and measure current.

 

 

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

The bad news is that this means the entire "clone" market may now be infected with bogus processors, with no practical way to tell the difference.

Unfortunately the market is riddled with this. I'd expect Microchip is already aware of this - it has been happening for years. You have to be suspicious when a complete pcb assembly is cheaper than you can buy the real chip for. 

 

The clone chip was probably designed by a group of uni students as a project - zero cost of design and teaching chip design skills is the win here. The local foundry had some spare production, so they run some wafers for the uni. Sell the chips to the local board assembly houses where they keep their line running with simple boards using the over run components from other projects. Sell to the rest of the world where they're happy to snap up stupidly cheap boards and happy to accept a few duds. We got what we paid for. 

The only 'problem' is the expectation that we would get real chips.

 

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

Peabody wrote:
I think that's the code he used to test the actual sleep current

Yes, it is.

 

Sorry - I thought that's what you were after.

 

blush

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Unfortunately the market is riddled with this

Yep - even Sparkfun have famously been victims:

 

https://www.sparkfun.com/product...

 

At least they got complete duds - no pretence at working at all.

 

Kartman wrote:
The clone chip was probably designed by a group of uni students as a project

I'm pretty sure there are HDL models of the AVR out there - so it would be easy to come up with a "work-alike".

 

But getting things like leakage current right is where the real skill - ie, money - comes in.

 

Kartman wrote:
We got what we paid for. 

The only 'problem' is the expectation that we would get real chips.

Indeed.

 

frown

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

And 'Xino Bao'?

 

Just not clear enough to be sure...

 

You know, those letters are somewhat strange, looks a bit like Cyrillic to me...

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

It might be worthwhile overclocking these clones to see if a faster fab process was used. What they lack in low power, they might gain in speed. Maybe something for Ralphdd?

I wonder how good the eeprom is??

 

 

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

Well, the die seems to be smaller, so maybe it's a faster process, but in that case probably the current drive capability is lower than real AVRs.

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

Quote:

 

Kartman wrote:

We got what we paid for. 

 

The only 'problem' is the expectation that we would get real chips.

 

Indeed.

 

But we've been guying $2-3 clone Pro Minis, Unos and Nanos for years that seemed to work just fine.  Are you saying those 328Ps were also probably counterfeits, just better ones?  I don't know, but when I was searching when this all came up, I didn't find a single confirmed instance of a 328P counterfeit chip.  So my conclusion was that the previous clones had genuine Atmel chips.

 

 

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

Peabody wrote:
we've been guying $2-3 clone Pro Minis, Unos and Nanos for years that seemed to work just fine (sic)

until you tried the low power modes!

 

Probably all this goes to show is that very few people are trying to get really low power with the cheap clones (or they may be trying, but not measuring).

 

Just goes to show how "but it's been working fine for years" really doesn't tell you much about latent faults/failings/limitations in a system.

 

Proven Product Syndrome strikes again:

 

https://www.avrfreaks.net/commen...

 

https://www.avrfreaks.net/commen...

 

https://www.avrfreaks.net/commen...

 

my conclusion was that the previous clones had genuine Atmel chips

quite possibly they did.

 

or they had different counterfeits - with different deficiencies

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

It might be worthwhile overclocking these clones to see if a faster fab process was used. What they lack in low power, they might gain in speed. Maybe something for Ralphdd?

I wonder how good the eeprom is??

 

I wouldn't be able to test much more than 40MHz.

http://nerdralph.blogspot.com/20...

 

Though I wouldn't mind a reason to pick up a couple si5351 clock gen chips...

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

With a small modification to avrdude.conf, you can read the extended signature bytes with a programmer; no need to compile & download code to the target.

http://nerdralph.blogspot.com/20...

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

Peabody wrote:

Quote:

 

Kartman wrote:

We got what we paid for. 

 

The only 'problem' is the expectation that we would get real chips.

 

Indeed.

 

But we've been guying $2-3 clone Pro Minis, Unos and Nanos for years that seemed to work just fine.  Are you saying those 328Ps were also probably counterfeits, just better ones?  I don't know, but when I was searching when this all came up, I didn't find a single confirmed instance of a 328P counterfeit chip.  So my conclusion was that the previous clones had genuine Atmel chips.

 

 

 

I seem to recall a couple cases of the LGT8F328P modules being used on pro-mini clones.  I've personally received LGT modules (advertized as such) where the chip had no markings.  The only reason I can think of why LGT would sell them that way is so counterfeiters can resell them as ATmega328p chips without have to blacktop them.

 

 

I have no special talents.  I am only passionately curious. - Albert Einstein