Can't get below 1.4mA in STANDBY with an ATTINY16

[intakenick]

I'm attempting to approach the low uA sleep power consumption that others here have been able to achieve but am unable. The only thing that could be pulling power on the board is a 100k resistor which is biasing a mosfet and connected to a GPIO (so that pin is pulled high and sinking some negligible current due to its high impedance path to ground). Interestingly, this is an old project that was started a long time ago on a very outdated version of this core. Back then, the sleep mode current was around 4uA. Code below:

`#include <avr/sleep.h>

#define RAIL 5
#define BUTTON 10

bool showtime=0;

int main() {
//Serial.begin(115200);
set_sleep_mode(SLEEP_MODE_STANDBY);
sleep_enable();
setRail(0);

while(1){
//Serial.println("Awake");
delay(1000);
sleep();

}
}

void wake(){
detachInterrupt(digitalPinToInterrupt(BUTTON));
pinMode(BUTTON, INPUT);
showtime = 1;
}

void sleep(){

for(int i=0; i<18; i++){
if(i != BUTTON && i != RAIL){
pinMode(i, INPUT_PULLUP);
//digitalWrite(i, LOW);
}
}
ADC0.CTRLA = 0;
//ADC0.CTRLA &= ~ADC_ENABLE_bm;

//ADCPowerOptions(ADC_DISABLE);
setRail(0);
while(digitalRead(BUTTON)==LOW){}
showtime = 0;
//Serial.println("Sleep");
delay(50);
attachInterrupt(digitalPinToInterrupt(BUTTON), wake, LOW);
sleep_cpu();
}

void setRail(bool enable){
if(enable){
pinMode(RAIL, OUTPUT);
digitalWrite(RAIL, LOW);
}
else{
pinMode(RAIL, INPUT);
}
}

And here's the power profile:

`

[SpenceKonde]

This was sorted out in issue #888 - issue was that it wasn't going into sleep mode at all because main was overridden and millis was was not disabled from the tools menu - but because main, which calls init, which calls the functions to initialize millis among many other things, was overridden, . The part that sets the clock speed was also not being called; so it was running at 1/6th of the expected speed, accounting for the power consumption being lower than it would have been otherwise while stuck in active mode. And it looks like because Serial.flush() wasn't being called before going to sleep, the part could have been getting immediately reawoken when the next character was done sending, since the TX module always stays awake until it finishes sending the current character.