Yes I noticed similar issue with my old AT89s52 Boards some times the development board acts dead and works again after a reset.
I am not sure but the power supply might contains some spike voltage or some noises which might cause MCU to act dead may be this happens because capacitors can not filter those spikes in the beginning using a well regulated (high ...
This is a generic method. The ubrr is an unsigned int which makes it 16 bits wide (2 bytes).
To break this into discrete bytes like in the example, you need to shift the bits right by 8 to get the high byte.
In your specific example it doesn't matter because the high byte is empty anyway, but what if you need a ubrr of 3,096?
Also, you might be confusing ...
This method doesn't work if we have a lot of code after a key press detection. I have changed my code and right now it looks like this:
#define KEY1_UP (PIND & (1 << PD2))
Your "working" code sets "key pressed" to zero by incrementing it, luckily it's uint_8_t. If that's intentional there should be a comment explaining that. this is undefined behaviour. (so don't compile with optimisation on)
Your "non-working" code has delay_ms(200) instead of delay_ms(10) resulting in twenty times more debounce ...
There's probably hundreds of sites with examples like this. Here's one: https://toastedcornflakes.github.io/articles/avr_getting_started.html
(Yes, it's a '328 not a '2560, but for one led, it's close enough to get us started.)
Also check out the support files at Microchip.com for the ATmega328 and ATmega2560. There's going to be examples and application ...