Why does port B5 on ATMEGA64A-AU malfunction after enabling USART function?

Question

I've wire up ATMEGA64A-AU based on this schematic from here:

I've tried to program a blink on pin B5 which has a LED on it:

#define F_CPU 16000000UL

#include <inttypes.h>
#include <avr/interrupt.h>
#include <avr/io.h>
#include <util/delay.h>
#include <stdlib.h>

void main( void )
{
    DDRB |= (1 << PB5);
    PORTB |= (1 << PB5);

    while (1){
        _delay_ms(1000);
        PORTB ^= (1 << PB5);
    }
} 

It works actually fine. But when I tried to enable USART on the chip by adding these:

#define FOSC 1843200 // Clock Speed
#define BAUD 9600
#define MYUBRR FOSC/16/BAUD-1

void USART_Init( unsigned int ubrr )
{
    UBRR0H = (unsigned char) (ubrr >> 8);
    UBRR0L = (unsigned char) ubrr;
    UCSR0B = (1 << RXEN0) | (1 << TXEN0) | (1 << RXCIE0);
    // Set frame format: 8data, 1stop bit 
    UCSR0C = (1 << USBS0) | (3 << UCSZ00);
}

It still work. But when I add this code to main function:

    USART_Init(MYUBRR);

Toggling stops!

Why does this happen? I couldn't found any thing on its datasheet. PB5 hasn't any thing to do with USART to my understanding.

PS:

This chip has some weird property like this but it comes with two UARTs and it is cheaper than the others! That is why I choose it.

Update 1:

ATMEGA64A has two fuse bit which was new to me :

1. ATmega103 compatibility mode fuse which was set as default and shouldn't be in my case.
2. JTAG fuse which I don't have a device to use it! I use ISP programmer, so it shouldn't be set.

It starts blinking after setting them, but still I don't understand how they got PB5 involve, they use other pins!

Answer 1

The register map of Mega64 and Mega103 are different, for example the Mega103 does not have UBRRH and UCSRC registers while the Mega64 does, so writing to these register addresses in Mega103 mode may control something else that hangs the processor.

To find out exacty what is the main reason, you need to debug it, but SRAM starts earlier on Mega103, so writing to the Mega64 extended register addresses maps to SRAM and it might overwrite data in RAM, but there is not much SRAM usage in the code, and stack should not be in that area.

So more likely is that the stack is at the end of the SRAM, and on the Mega103 the memory ends earlier due to not having the extended registers, so running Mega64 code in Mega103 mode puts the stack into non-existing memory area, so stack is unavailable. Calling subroutines will fail to push the return address and returning from a subroutine pops the wrong address.