AVR Freaks

The fact that you can reset the slave anytime and the master will cope just fine suggested me that the problem was with the slave not coping well with an interrupted transmission, or something like that. However, I might be wrong: it would help to know which of the slave or the master actually is left hanging in the wrong state…

On the master side, the only problem I can figure would be a failed setup. For example:

• Bit 4 – MSTR: Master/Slave Select
This bit selects Master SPI mode when written to one, and Slave SPI mode when written logic zero. If SS is
configured as an input and is driven low while MSTR is set, MSTR will be cleared, and SPIF in SPSR will
become set. The user will then have to set MSTR to re-enable SPI Master mode.

Admittedly, this is from the ATmega328 datasheet, not the Atmega644a. I don't see how that could happen though: your master code sets DDRB before SPCR. Perhaps you can double-check that the generated assembly does to.

On the slave side, the problem would have to come from an interrupted transmission.

I'm not sure how the ATmega SPI hardware deals with that issue. For example, what happens if SS is released in the middle of a transmission? I can't find information about that in the ATmega datasheet. We could imagine the interrupt never triggers because the end of transmission is never reached…

If the HW does the right thing (which is likely), what in your slave code could go wrong?
Assuming the interrupt triggers alright, the ISR would have no impact only if the buffer was full. In other words, the highlighted condition would always be false:

ISR (SPI_STC_vect)
{
byte c = SPDR;  // grab byte from SPI Data Register

  // add to buffer if room
  if (pos < sizeof buf)
    {
    buf [pos++] = c;

    // example: newline means time to process buffer
    if (c == '\n')
      process_it = true;

    }  // end of room available
}  // end of interrupt routine SPI_STC_vect

… thus process_it would never be set to true, thus the main loop() would never send anything to Serial and the communication would look stalled.

I see two possibilities for this to happen:

1. the buffer gets full before any "\n" has been received. For example, because buf is not big enough to hold both an interrupted message (received before master reset) and another full one (received after master reset). Hard to tell, cause you haven't posted the part of your code creating the messages. To make sure this isn't the case, make sure buf is at least twice as big as the longest message.
2. the buffer receives a full message (with a "\n") and sets process_it to true before the last message has finished being sent on Serial and process_it is reset (this could happen because serial is slow and process_it is reset at the end of your handling code). In this case, that new message would be ignored and the buffer would keep on filling.

if (process_it)
    {
    buf [pos] = 0;
    Serial.println (buf);
    pos = 0;
    process_it = false;
    }  // end of flag set

Anyway, that slave code looks really bad. It doesn't handle concurrent access (between the ISR and the main loop) correctly. Other things could go wrong although they would more likely end up with mangled messages than a hanged slaved.

An easy "fix" (not a real fix!) would be to move the process_it reset at the beginning, like so:

if (process_it)
    {
    process_it = false;
    buf [pos] = 0;
    Serial.println (buf);
    pos = 0;    
    }  // end of flag set

Alright. So I suspect what happens is that, if the master resets in the middle of a transmission, the slave then assumes what it gets after the master comes back online is the remainder of the interrupted transmission. In other words, the slave interprets the first bits of the new transmission as being the last bits of the interrupted one.

If someone more knowledgeable about HW SPI behavior could confirm that, it'd be nice.

Anyway, as written earlier, there are still issues that need to be fixed with the slave code.

Suppose for example that you receive new data while sending the last message to Serial: the first bytes will be appended at the tail of the buffer,  then Serial finishes and reset pos, thus the next bytes are now written at the beginning of the buffer. So your new message loses all its first bytes:

if (process_it)
    {
    process_it = false;
    buf [pos] = 0;           // new bytes arrive while slave is writing to Serial:
    Serial.println (buf);    // first bytes go to buf[pos], buf[pos+1], etc.
    pos = 0;                 // next  bytes go to buf[0], buf[1], etc.
}

In fact, it could be even worse: the first byte arriving could overwrite your ending 0, thus println() wouldn't know where its string ends…

If you need that functionality in you project, I'd strongly suggest to redesign the slave code entirely.

I tried software resetting the Arduino after the Atmega master resets but still no difference, it really needs a reset from the reset pin for the SPI to start working again.

If my above hypothesis about HW behavior is right, I suppose you'd have to reset the slave SPI. Perhaps emptying SPDR would be enough. I suppose clearing and setting the SPE bit in the SPCR register would work. In any case, your slave code would need a way to realize what happened.

Perhaps you can share the reset line between the master and the slave…

But how often do you expect the master to reset while the slave does not?

Then I guess you could delay the slave power on a bit, one way or another.
 

Then I see no other solution but controlling the slave reset from the master…