AVR ATmega328P if statement wrongly executed after reset

Question

I have simplified the listing to bare minimum where I can still observe this behaviour.
When this program is running, it works as expected. Button press causes LED to show up.

The problem exist on first run: when I run it first time (powering up) or resetting the processor the body of if (!(PINC & (1<<PC0))) is executed despite that the condition is not met (button not pressed).
Code:

#include <avr/io.h>
#include <util/delay.h>

int main(void) {
  DDRB |= (1<<PB5); // pin for LED as output 
  DDRC &= ~(1<<PC0); // to ensure PC0 is input - btn here, shorts to gnd when pressed 
  DDRD |= (1<<PD0)|(1<<PD1); // debug LED1 and LED2

  while(1) {
    PORTC |= (1<<PC0); // pull-up
    asm( "nop " ); 
    asm( "nop " ); 

    if (!(PINC & (1<<PC0))) {  //btn pressed? shorts to gnd
      PORTB |= (1<<PB5); // LED on <-- executed after RESET!
      // here comes extra code to move stepper motor
    }
    else {
      PORTD |= (1<<PD1); // dbg LED on
    }
    _delay_ms(2000);
    PORTB &= ~(1<<PB5);
    PORTD &= ~(1<<PD1);
  }
}

Is here something I am not aware of?
Extra info: this would be a small nuisance if comes as LEDs only, but I want some step motor movement (or rather - NO movement). This execution is undesired just after powering the processor up.

EDIT
More info: The hardware is Arduino UNO SMD.

Code is written and compiled with Arduino IDE.

Wires connected between pushbutton switch and the PC0 (or A0, using Arduino description) with about 15cm long wires. This pushbutton shorts PC0 to gnd.
No external (hardware) pullup/pulldown.

Answer 1

As there is no external pull-up, the internal pull-up of the AVR is so weak that the voltage on the pushbutton pin rises slowly.

The two NOP delay is only to compensate the delay caused by the synchronizer, so you get data there was on pin 2 clock cycles ago, right after the moment the pull-up was activated.

But the voltage was still rising and below the threshold of logic 1 level.

It is best to use initialize the pull-up at startup, maybe have an explicit delay of few microseconds to wait that the voltage has risen to supply voltage, before reading the pin state for the first time.

Answer 2

The unwanted led activity on PB5 is caused by the bootloader on that Uno clone. Possible solutions: Chose a pin other than PB5 to avoid spurious switching at start up or eliminate the bootloader.