328P sleep current wildly different between two copies

Go To Last Post
152 posts / 0 new

Pages

  • 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

 

Pages