ATMega328-PU marked as ATMega328P-PU

[sleemanj]

Just received a batch (20) of what were supposedly ATMega328P-PU from an aliexpress supplier I've used before without issue.

Came in atmel branded tubes.  IC's marked as ATMega328P-PU. Just the same as the last batch from the same place which were totally fine.

This time however;

 avrdude: Device signature = 0x1e9514
 avrdude: Expected signature for ATMEGA328P is 1E 95 0F

Erp.  1e 95 14 is the non-p version.

Not that it really makes a blind bit of difference to the majority of people if it's P (pico power) or not, but something to watch out for. 

Added the appropriate jibber jabber to avrdude.conf so I could program them.

[jeremy]

Interesting. Do they look burned at all on the surface? Can you post some pictures?

[sleemanj]

Interesting. Do they look burned at all on the surface? Can you post some pictures?

They look completely normal.  If I had a guess, I'd say they were mis-marked at the factory.

Here's some photos as best I can manage (I find it hard enough to read IC markings, let alone photograph them) of both mislabelled ones and one that is labelled correctly for comparison.

http://imgur.com/a/nzk7G

[jeremy]

The bad one seems to have blurrier/thicker lines, it is more noticeable in the atmel logo? Not that I would have spotted this if I didn't know one of them was bad. Is this the case with all of them?

[dannyf]

They look completely normal.

I think they are fake / repackaged: the pins extend from the body a little bit more before they start bending, and when they do that, they don't bend so straight (90 degrees).

[sleemanj]

The bad one seems to have blurrier/thicker lines,

No that is just my shakey hands holding the camera and a flashlight, there is no discernible difference in the quality of marking to my eye.

Well, seller has replied:

The item we sent to you is 100% new and orgiinal part!
Pls don't worry!

Pls try to test it and you will see that it ie new and original  ATMEGA328P-PU .

in response to my message that they have the wrong signature, probably not going to get any further with an resolution there so I'll name them now as a warning to others - False/Fake Marked ATMega328 sourced from Mega Semiconductor Ltd   - but of course I can't imagine this is an isolated incident, if they have been mislabelled (or relabelled) then I don't know how big a typical production run is, but I'm pretty sure it's going to be larger than just one aliexpress seller can dump.

[sleemanj]

Hmmm, curiouser and curiouser.  I did a bit more googling and found somebody who had the opposite problem, a lone 328P signature in a batch of 328 labelled chips, and somebody suggested that it might be a wrong signature rather than wrong label, it seems unlikely to me, but...

The difference in capability between the P and non-P is primarily that the P can disable brown out detection in software, the non-P can't.

So it seems reasonable that trying to disable the BOD might give some clues...

Arduino code...

Code: [Select]

void setup() {               

  Serial.begin(9600);
 
  // prints title with ending line break
  Serial.println("BOD TEST");
 
}

// the loop routine runs over and over again forever:
void loop() {

  Serial.println("Before Setting");
  Serial.println(MCUCR & _BV(BODS), BIN);

     
  Serial.println("After Setting");   
  MCUCR = _BV (BODS) | _BV (BODSE);
  MCUCR = _BV (BODS);
  Serial.println(MCUCR & _BV(BODS), BIN);


delay(1000);
 
}

Produces...

Code: [Select]

BOD TEST
Before Setting
0
After Setting
1000000
Before Setting
0
After Setting
1000000

on both the 328P signatured chips, and the 328 signatured chips, identical, the register change is accepted, and then reset accordingly.

So, scratching head now, I guess it's possible that the bit change is seen to be accepted even if BOD can't be disabled, I don't have a chip I absolutely know is a non-p 328 to see :-/

[dannyf]

What about current consumption?

[MLXXXp]

Arduino code...

Code: [Select]

  Serial.println("After Setting");   
  MCUCR = _BV (BODS) | _BV (BODSE);
  MCUCR = _BV (BODS);
  Serial.println(MCUCR & _BV(BODS), BIN);


I know very little about coding for Arduino. Is there a chance that MCUCR needs to be declared volatile, to avoid compiler optimisation on the read?

[sleemanj]

What about current consumption?

A naive check yields no discernible difference in general power consumption.

[dannyf]

to avoid compiler optimisation on the read?

It is defined as such in the header file.

[janoc]

Well, it wouldn't be the first time fake ATMegas were spotted in the wild:

https://www.sparkfun.com/news/350

[sleemanj]

Well, it wouldn't be the first time fake ATMegas were spotted in the wild:

https://www.sparkfun.com/news/350

Yes, but these are not quite THAT fake (sparkfun got shipped a reel of some totally random On Semi thing labelled as ATMega328, a few years ago).

[dannyf]

quite different stories, however. The sparkfun one is a complete fraud. This one here is functioning (so far).

[MLXXXp]

to avoid compiler optimisation on the read?

It is defined as such in the header file.

OK, thanks. Upon doing a little digging, it looks like it's done here, in sfr_defs.h:

Code: [Select]

#define _MMIO_BYTE(mem_addr) (*(volatile uint8_t *)(mem_addr))

[sleemanj]

Well, I'll be.  I think these really do have the wrong signature, not the wrong label.

I decided the only way to really test it, was to test the brown out detection. 

The brown out detection works simply by putting the cpu into a reset loop when power browns out, when the power comes back good the reset loop stops and the cpu resets normally.  So the quick code below flashes an onboard led a few times at boot/completed reset, turns off brown out detection, and goes to sleep.

With the brown out detection turned off, once sleeping if I dial the volts back to 3.5v the power consumption is circa 850uA, and dialling the volts back up does not cause a reset, indicating that the brown out did not trigger and everything is still sleeping.  I do not see a reset on return to 5v+ until the voltage goes down to somewhere under 3v.

With the brown out detection left on (commented out the MCUCR lines), dialing the volts back to 3.5v the power consumption is circa 1000uA, AND it resets as it passes back through 5.something V on the way up.

NB: measurements on cheap-ass meter, the absolute values could be way out, it's the relative difference which is interesting here.

So from that, I think that the only conclusion is that the brown out detection disabling is working, and so, these must be 328P which have a wrong signature, that of a plain, non-p 328.

Can anybody see a flaw in my thinking?  Any other ways that I could verify?

Code: [Select]

// the setup routine runs once when you press reset:
#include <avr/sleep.h>
void setup() {               

  Serial.begin(9600);
 
  // prints title with ending line break
  Serial.println("BOD TEST");

pinMode(13, OUTPUT);


for( int x = 1; x <= 5; x++)
{
  digitalWrite(13, HIGH);
  delay(100);
  digitalWrite(13, LOW);
  delay(100);
}

}

// the loop routine runs over and over again forever:
void loop() {

  Serial.println("Sleeping...");   
  delay(500);
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_enable();
 
  MCUCR = _BV (BODS) | _BV (BODSE);
  MCUCR = _BV (BODS);   
 
  sleep_cpu();
  sleep_disable();
  Serial.println("Waking...");     
  delay(1000);
 
}


[Neverther]

Atleast attiny13/a non-picopower devices dont have PRRs (Power Reduction Registers) defined.
Disabling stuff via those can be seen in power consumption on tiny13a.

[Stonent]

Might be worth it dropping a line to Atmel and seeing if they have seen this before.  It could also be legitimate chips produced fraudulently.  Sometimes factories have been known to produce a little extra than was documented in the books and sell them through an unlicensed distributor.  Typically this is nearly impossible to tell except when little mistakes are made, like forgetting to change the device signature that's burned in at the factory.

They could also be manufacturing seconds that failed QA and were not properly disposed of.

Again, Atmel could probably give you some information on what to look for.

[amyk]

The signature bytes are writable via an undocumented programming command,  since they're stored in flash as well.

Here's something interesting I found, you may want to read out the rest of the signature bytes and compare to the bottom marking:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1140073

[sleemanj]

The signature bytes are writable via an undocumented programming command,  since they're stored in flash as well.

Here's something interesting I found, you may want to read out the rest of the signature bytes and compare to the bottom marking:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1140073

Interesting.

Given that the signature bytes are flash stored, it makes a lot more sense to me now that they could be wrong and the markings right.  The "ghost shift used the wrong configuration" type of situation is quite possible.  Or maybe it was a special order where a large purchaser has a system that depends on 328 but the factory only produces 328P so they fiddled the signature for them... and then the ghost shift kicked in and just ran with the same settings.

That said realistically it's not worth me spending much more time on at this point, I think from skimming those links that a HV programmer would be required to change the signature bits, and the difference between the P and non-P is so minimal in practical terms, it's easier to just chuck on a boot loader, and call it a day.  Once the bootloader is up, it's a 328p to anything talking to that bootloader, since they all just hard code the signature bytes in the bootloader and report that anyway.