ATMega328-PU marked as ATMega328P-PU - Page 1
Forum section: electronics / general

author: sleemanj
author_rank: Super Contributor
timestamp: May 09, 2014, 10:27:56 am
content: 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 = 0x1e9514avrdude: Expected signature for ATMEGA328P is 1E 95 0FErp. 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.

author: jeremy
author_rank: Super Contributor
timestamp: May 09, 2014, 10:55:39 am
content: Interesting. Do they look burned at all on the surface? Can you post some pictures?

author: sleemanj
author_rank: Super Contributor
timestamp: May 09, 2014, 11:14:32 am
content: Quote from: jeremy on May 09, 2014, 10:55:39 amThey 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

author: jeremy
author_rank: Super Contributor
timestamp: May 09, 2014, 11:20:27 am
content: 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?

author: dannyf
author_rank: Super Contributor
timestamp: May 09, 2014, 11:27:29 am
content: QuoteI 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).

author: sleemanj
author_rank: Super Contributor
timestamp: May 09, 2014, 12:05:53 pm
content: Quote from: jeremy on May 09, 2014, 11:20:27 amNo 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:Quotein 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.

author: sleemanj
author_rank: Super Contributor
timestamp: May 09, 2014, 01:21:23 pm
content: 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:void setup() {Serial.begin(9600);// prints title with ending line breakSerial.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:BOD TESTBefore Setting0After Setting1000000Before Setting0After Setting1000000on 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 :-/

author: dannyf
author_rank: Super Contributor
timestamp: May 09, 2014, 01:28:33 pm
content: What about current consumption?

author: MLXXXp
author_rank: Frequent Contributor
timestamp: May 09, 2014, 01:55:13 pm
content: Quote from: sleemanj on May 09, 2014, 01:21:23 pmI 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?

author: sleemanj
author_rank: Super Contributor
timestamp: May 09, 2014, 02:05:36 pm
content: Quote from: dannyf on May 09, 2014, 01:28:33 pmA naive check yields no discernible difference in general power consumption.

author: dannyf
author_rank: Super Contributor
timestamp: May 09, 2014, 02:13:42 pm
content: QuoteIt is defined as such in the header file.

author: janoc
author_rank: Super Contributor
timestamp: May 09, 2014, 02:15:22 pm
content: Well, it wouldn't be the first time fake ATMegas were spotted in the wild:https://www.sparkfun.com/news/350

author: sleemanj
author_rank: Super Contributor
timestamp: May 09, 2014, 02:21:00 pm
content: Quote from: janoc on May 09, 2014, 02:15:22 pmYes, 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).

author: dannyf
author_rank: Super Contributor
timestamp: May 09, 2014, 02:21:36 pm
content: quite different stories, however. The sparkfun one is a complete fraud. This one here is functioning (so far).

author: MLXXXp
author_rank: Frequent Contributor
timestamp: May 09, 2014, 02:22:55 pm
content: Quote from: dannyf on May 09, 2014, 02:13:42 pmOK, thanks. Upon doing a little digging, it looks like it's done here, in sfr_defs.h:Code:#define _MMIO_BYTE(mem_addr) (*(volatile uint8_t *)(mem_addr))

author: sleemanj
author_rank: Super Contributor
timestamp: May 09, 2014, 03:22:11 pm
content: 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:// the setup routine runs once when you press reset:#include <avr/sleep.h>void setup() {Serial.begin(9600);// prints title with ending line breakSerial.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);}

author: Neverther
author_rank: Regular Contributor
timestamp: May 09, 2014, 04:30:30 pm
content: 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.

author: Stonent
author_rank: Super Contributor
timestamp: May 09, 2014, 06:59:43 pm
content: 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.

author: amyk
author_rank: Super Contributor
timestamp: May 10, 2014, 12:52:36 am
content: The signature bytes arewritable 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

author: sleemanj
author_rank: Super Contributor
timestamp: May 10, 2014, 01:26:05 am
content: Quote from: amyk on May 10, 2014, 12:52:36 amInteresting.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.