A year ago I ordered a 3.3V 8MHz Pro Mini clone from Ebay for use in a TV IR remote. I removed the regulator and the power-on LED, and was able to get the Power-Down sleep current down to a fraction of a microamp. It was powered directly from an 18650.
Yesterday I received two more 3.3V 8MHz Pro Minis from a different Ebay source, and have tested one of them after making the same modifications to it. The Power-Down sleep current is about 150µA. That's with the exact same test sketch flashed.
Since the sketch is identical, and nothing is connected to the Minis during the tests except power and ground, I'm trying to figure out why there is such a big difference in the sleep current. One explanation is that the processor on the new Mini isn't a genuine Atmel. The only other thing I can think of is that the bootloader, and perhaps the fuses, are different in some way that affects sleep current. Does anyone have any ideas about this? Is it possible to read out the fuse values? The bootloader?
Any suggestions would be appreciated.
Here's my test sketch. It just goes into Power-Down sleep, and never wakes up.
#include <avr/sleep.h>
#include <avr/wdt.h>
int i;
void setup(){
for (i = 2; i < 20; i++) { // all pins to one rail or the other - power saving
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(){
}
The code you are using does not appear to turn off all the various on-chip modules, via the PRR (Power Reduction Register), so you might look into doing so. That is covered in this highly recommended and thorough tutorial: https://www.gammon.com.au/power
I use Atmel Studio on Windows to do things like read out the fuses, copy/reflash the bootloader, etc. It has a handy disassembler and other useful tools as well.
The ancient Studio 4 is very easy to use, works great for such applications and is still available, but you will need an ISP programmer that behaves like the Atmel ones to use it effectively. Atmel Studio 7 is more advanced but less easy to use.
I particularly like the Pololu V2.1 AVR-ISP programmer, as it doubles as a serial port and an "FTDI" style programmer. Effortlessly switches between 3.3 and 5V chips. Best I've ever used!
With those tools you could update the new chips to be identical to the old chip, in terms of bootloader code and fuse configurations .
Well, it may be like the guy looking under the street light for his car keys. He didn't remember dropping them there, but it's the only place with any light. So if both old and new Minis have been modified the same way, and if both have been flashed with exactly the same sketch, it appears the only thing that could be wrong (that I can fix) is the bootloader/fuses. I've never done it before, but it seems I can flash a Nano with a sketch making it an "Arduino as ISP" and burn the Pro Mini with the stock bootloader and fuses. If that doesn't fix it, then I guess it's just a bad copy or a fake processor. And I guess I could use it for things not requiring a low sleep current. Of course that's why I bought it. Otherwise I'd just use a Nano.
I just wish there was a way to read out the bootloader from the old Mini and write it to the new one. It looks like I can use the Nano and Avrdude.exe to read out the fuse settings, which I may try to do. The only setting I see that might explain this is the one to have the WDT always On. But I'm not really familiar with the fuse settings, so there might be something else.
Ok, I was able to figure out how to use Avrdude to read out the bootloader code and fuse settings from both the old and new Minis. They are identical to each other in all respects, and the bootloader is the stock version. So that eliminates all of that as an explanation.
I have to conclude that it's something like a leaky capacitor or other one-time problem that I hope won't happen again. But I do have a second copy of the new Mini, so it's time to solder on the headers, remove the power LED and regulator, and see if this happens again. If it does, then the manufacturer is using a sub-standard part, or something similar, and I would just need to find another source for these things. But hopefully the second one will work ok.
The second one is just like the first one - it sleeps at 150µA. So I think it has to be a problem with the processor. But I have to say, this is very strange.
For future reference, I wasn't able to find anything on the PC boards to explain the excessive sleep currrent. So I've concluded the problem is the processor, and since I can't fix that, I'll have to order replacements from a different source. But there is a nagging suspicion that there's been a 328P revision, design change, eratta, or whatever that's not in the datasheet and that would explain what's happening. So I guess I won't be totally surprised if the new batch behaves the same way. Hope not though.
A simple test is to dump the signature bytes plus some other unknown identifiers using this code:
//found this code here
//https://gist.github.com/speters/f889faec42b510052a6ab4be437d38ca
//Purpose is to simply run a memory check on ATMEGA238P to test for counterfeit parts
// CODE BELOW downloaded from https://gist.github.com/krdarrah/6e6cb94c1df015e8e9f910ae5cf85299
#include <avr/boot.h>
#define SIGRD 5
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
Serial.println("");
Serial.println("boot sig dump");
int newLineIndex = 0;
for (uint8_t i = 0; i <= 0x1F; i += 1) {
Serial.print(boot_signature_byte_get(i), HEX);
Serial.print("\t");
newLineIndex++;
if (newLineIndex == 8) {
Serial.println("");
newLineIndex = 0;
}
}
Serial.println();
}
void loop() {
}
Results I get from known good samples include the following. Bad ones are reported to have mostly FFs.
known good pro minis, with package markings.
boot sig dump 328P/AU 1437 (5V)
1E 93 95 FF F D2 FF 26
FF 8 FF 17 FF FF 57 34
35 36 30 39 FF F 12 2
17 1 12 6 13 6 FF FF
boot sig dump 328P/1343 (5V)
1E 8A 95 FF F F1 FF 26
FF C FF 17 FF FF 58 33
34 32 34 38 FF 16 25 21
17 1 12 6 13 6 FF FF
boot sig dump 328P/U-TH/35473D/1834QYP (3.3V)
1E 8A 95 FF F F1 FF 26
FF C FF 17 FF FF 58 33
34 32 34 38 FF 16 25 21
17 1 12 6 13 6 FF FF
srnet:
What do the results look like for a 'bad sample'?
Documented beginning at about 3:50 here
I’ve yet to find any duds in my inventory to post the results directly. I haven’t bought any ‘328s for quite some time.
PS: I’m fairly certain the OP knows what’s going on since the same user name is the source of the counterfeit devices examined over in the much longer thread on the EEVBlog.
Yes, as the latest Kevin Darrah videos show, a bad chip has been decapped, and it clearly isn't Atmel. So it appears we now have counterfeit 328P processors that could be in any Uno, Nano or Pro Mini clone, or anything else that uses a 328P, and in at least one respect - sleep current - they don't work properly. We don't know what else, if anything, might be wrong. So far, it seems only chips with date code markings in 2019 are bad.
Here's the output of the test program run on my last remaining bad chip. I think it's typical of the counterfeits.
boot sig dump - 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
I can't help with your problem but I can say I have also come across this exact problem with a clone ProMini used for prototyping then a later revision clone pro mini used in the final design - and then as you say, terrible sleep current in the same board/same sketch compared to the original.
