Reset SPI communication (3-wire mode)

Teh 3 wire/4 wire naming is misleading. It only means the hardware-level support of the SPI, not the required wires of the SPI communication itself. Usually, you'll always need 5 wires, including GND and a CS line.

The problem with the plain SPI data transfer is that it is not synchronized. Of course, each bit is sent with a clock pulse, but there is nothing determining the byte borders, or the start or stop or abort of a communication. This is where you'll need teh CS line.

Teh STE pin, however, is only partial support of a chip select. IT will, if pulled high, disable the slaves data output and stop the clocking of the shift registers, but it will not reset the shift registers and it cannot, ogf course, reset any high-level protocol.

So if you're doing your own slave, you should connect the masters CS signal with not only STE but also with an interrupt-capable port pin (I'd like to see an STE transition causing an interrupt by itself!).

So if CS is pulled low, you'll get an interrupt and can immediately start stuffing the TXBUF with data. You only have some microseconds, if at all. Then, if CS it set high, you should also immediately reset your SPI hardware, reconfigure it, and (if the type of data allows it) put the first byte into TXBUF already.

I think this is what is meant by 'resetting the slave'. It is not necessary to do a complete device reset at all, only the communication must be reset. But performing a complete device reset is fo course the very simplest way to do this.
Pulling the plug is surely the easiest way to reset your TV to the first channel. But 'some' people use the remote control instead.

It's a good approach to define the protocol in a ways that leading FF bytes are 'busy' bytes or 'don't care' , so you have enough time to prepare the data when the call comes. Remember, on SPI, the master won't wait for your answer. If the call comes, be ready. Immediately. Within nanoseconds.

While being an SPI master is the simplest thing on earth, being an SPI slave is a real slave job. If speed isn't an issue, I'd recommend going for an I2C master/slave instead.

Voyager34 said:

the slave may get clock edges an shifts in first bits in its shift register

This shouldn't happen if both are powered from the same power source and the port pins are initialized properly.
Yet it is indeed possible to catch some noise. Putting an external pullup to the clock line to VCC will eliminate this.

Voyager34 said:

So it seems that the TI sample code resolves this issue by keeping the slave as long in reset state as the master initializes its I2C module

  It is surely not a good thing to reset the slave just because the master resets. Imagine the slave being an MSP with RTC. The reset signal wil reset teh content of the RTC registers. Baaaad thing.
A typical cheap solution that will only work on the demo code but not in a real world application.

For the 'initialisation' the chip select signal is the usual and obvious solution. The slave initializes the SPI hardware but keeps the SWRST bit set. As soon as the CS line goes low, SWRST is reset and the first (dummy?) byte is put into TXBUF as fast as possible.

Having an interrupt on the STE pin and having the STE pin connected with the SWRST bit (if required/configured) would be a really nice thing and make life much easier.
But since this is not the case, the slave protocol must define a sufficient (worst-case) delay between CS and the first clock pulse.
Well, with the RESET solution, (assuming teh reset signal as a CS signal) this is a loooong time. :(