Electronic – Micro-controller failure problem as the temperature raises

A debug LED (You can convert it into a watchdog blinky later to verify that your main loop/1ms interrupt or whatever you're using is still running) is something that I would consider pretty mandatory for an exploratory board. Hello World on your new PCB does not need to be as complex as an LCD. You could repurpose a backlight controlling MOSFET for this purpose if you don't want to add the real components.

I'm assuming you're giving yourself some form of breakout for your extra pins - An LCD screen is great, and I understand the desire to keep it simple, but there's little that can go wrong simply by adding a trace to nowhere, and nowhere can become somewhere someday. Even if you don't want to add real headers, some test points (in the form of staggered rows of .05x.1" copper pads) will let you solder and hot glue some wires on later. This doesn't have to be a big deal. I'd put some jumpers/resistors on those lines, so you can add some 1k resistors to protect your pins from being shorted or hit with ESD if you decide to do so. This also gives you the ability to pull any of your other pins high or low if later you find this is necessary!

One thing that I do on a first board is add a lot of vias. Vias are your friends when making modifications (assuming you're getting this done at a PCB house and don't have to drill them yourself). If you've got two vias on every trace, even if you don't change sides with your trace, you can cut the trace later with an Xacto and run 30-ga wire wrap wire between the traces that need to be swapped (Make sure your vias are big enough for this, though). You can also add 0805 0-ohm jumpers (solder bridges are cheap; you don't need to buy components) and solder wires to the pads later if you don't like the via method. Probably won't be necessary, but it's cheap/free insurance.

Oh, and connect the LCD/USB setup first, then tack wires on temporarily from your working breadboard to make sure that the externals are working.

Another answer: Stop using interrupts.

People jump to use interrupts too easily. Personally, I rarely use them because they actually waste a lot of time, as you are discovering.

It's often possible to write a main loop which polls everything so rapidly that's it's latency is within spec, and very little time is wasted.

loop
{
    if (serial_bit_ready)
    {
        // shift serial bit into a byte
    }

    if (serial_byte_ready)
    {
        // decode serial data
    }

    if (enough_serial_bytes_available)
    {
        // more decoding
    }        

    if (usb_queue_not_empty)
    {
        // handle USB data
    }        
}

There might be some things in the loop which happen far more often than others. Perhaps the incoming bits for example, in which case, add more of those tests, so that more of the processor is dedicated to that task.

loop
{
    if (serial_bit_ready)
    {
        // shift serial bit into a byte
    }

    if (serial_byte_ready)
    {
        // decode serial data
    }

    if (serial_bit_ready)
    {
        // shift serial bit into a byte
    }

    if (enough_serial_bytes_available)
    {
        // more decoding
    }        

    if (serial_bit_ready)
    {
        // shift serial bit into a byte
    }

    if (usb_queue_not_empty)
    {
        // handle USB data
    }        
}

There might be some events for which the latency of this approach is too high. For example, you might need a very accurately timed event. In which case, have that event on interrupt, and have everything else in the loop.