SPI channel on MSP430F235 being overrun by DM365?

In the other thread you say you're running the SPI at >600kHz SPI clock. This does not leave much time for the MSP to react on an interrupt and move the RX buffer content to the TX register for echo.
Even worse, as slave you'll need to manually activate and deactivate the USCI module based on CS line.
If you use STE (4-wire slave mode), it will only inhibit the SOMI output and make the clock input inactive. It will NOT reset the internal state machine or reset the input/output shift. As soon as you release STE, things continue as if the time in between had never happened. In 4-wire master mode, STE does reset the state machine, yet you're not notified, so you stil have to check.

So you have to check the STE line in software to know whether the protocol has to be reset. It can be done by routing the CS signal not only to STE but also to a pin that can trigger an interrupt (either P1/P2 edge-triggered interrupt, or a timer's CCR input, so you'll get a capture interrupt). If the interrupt comes, you know that the bus has been freed by the STE hardware, but you'll also have to reset your protocol logic and the USCI.

John Walker said:

calculate from MSP430F235 spec sheet that it can theoretically support a slave SPI frequency Fs=3.9MHz

How did you calculate this? on 3V, I get a theoretical maximum of 6,666MHz (on an ideal master), for 2.2V it is 4,54MHz. Okay, knowing the masters limitations, 3,9MHz sounds reasonable.
However, on ~4MHz, you only have 4 MCLK cycles between receiving a byte and the start of sending the next. Luckily the MSP has its double-buffering feature, which relaxes things a bit, bu tin echo mode, you'll likely be uable to copy the incoming value to the output in time, so you'll likely have a two-byte delay.

Personally, I never used an MSP as SPI slave, as it is too timing-critial to be handled easily. I always suggest implementing an I2C slave instead, if possible. Being an SPi master, however, is fun and I use it for reading/writing SD cards without problems (on 3.6V, even 16MHz bit clock worked on an MSP430F5438 - of course I had to use DMA to make any use of this speed).

Somewhere in the othe rthread I read somethign about 'SPI mode 0, only one device, no CS' - you NEED CS, else you don't know the initial byte border. Without it, you have no synchronizing beyond single bits. You have, however, to synchronize the USCI hardwa  emanually on this signal.

One more thing: the USCI allows to select polarity and phase of the clock signal. If polarity and phase are both wrong, things sometimes seem to work and sometimes don't, based on clock frequency and the masters timings. In a certain window, the switched phase compensates for the switched polarity, but if this fails, you'll get bit shifts and/or more or less random values. Without scoping the signals, you cannot even tell whether the MSP is receiving the data right and the master gets the echo wrong, or whether the MSP is already receiving garbage.

John Walker said:

when we transmit, we are generating 80KHz IRQs on the poor MSP430.  Is there a way to modify the DM365 SPI minimum rate below 600KHz?

I don' t know, but you can switch from interrupt-driven mechanics to polling the interrupt flags. It saves you the combined cycles for interrupt latency and ISR return. With 16MHz system clock and 4MHz SPI clock, you only have 32 clock cycles per byte. And at least 11 of them (plus the remaining cycles of the currently executed main instruction) are required for entering and exiting the ISR. Of course, when doing busy-waiting instead, you cannot do much useful work in-between.

If the transmissions come in bursts, you can perhaps react on CS (ISR triggered on port or CCR), then you stay in the ISR and do a busy-waiting handling of the burst transfer, then exit the ISR.

Best hting, of course, would be a different MSP which is suited better for this purpose (e.g. one with DMA) :)