Piccolo to MSP430G2553 SPI interface in 3-wire mode

Hello Hamid,

The question here is partially, "What does 3-wire SPI mean?"

In SPI implementations, the clock is always necessary and is generated by the master. 

The usage of the other "3" signals depends on the usage. 
SPISIMO/SPIMOSI - Only needed if data will be transferred from the master to the slave
SPISOMI/SPIMISO - Only needed if data will be transferred from the slave to the master
SPISTE/CSn - Used to enable the slave/select a specific slave.  In many implementations, the slave's CSn signal can be pulled to low and this signal does not need to be transmitted from master to slave.

As you can see, there are some SPI implementations where only a 2 or 3 wires may be adequate to meet the requirements of some projects.

The C2000 SPI peripheral's "3-wire" mode, that you mentioned, is special mode where the SPISIMO and SPISOMI signals are combined and the shared signal will be time multiplexed between master & slave data.  Most SPI implementations are not this way and the MSP430 may not support this format. 
(note that as above, if multiple slaves are not used and the slave doesn't require CS for timing, the CSn/STE signal may not be necessary in a 3-wire implementation thereby making it utilize 2 wires) 

Hopefully, this clarifies things some. :)


Thank you,
Brett

Hi Brett,

Thanks for the reply. I have configured a PICCOLO as the master, in 3-wire mode (As instructed in section 12.1.7). This master needs to send different commands to multiple slaves (MSP430G2553) which have also been configured in 3-wire mode (NO STEx/CS signal). I have followed the example 12-4 in the user manual for the transmit and receive operation on the master side. Also I have connected the SPISOMI and SPISIMO of the MSP430 together and connected to  PICCOLOS SPIMIMO (SPISIMO 4-wire config) and I have set the TRIWIRE bit in the SPIPRI register (Set also TALK bit in SPICTL to transmit). But when I run the images on the targets ,I do not see anything happening, no signals on the scope, not even SPICLK. while everything works fine in 4-wire mode. Am I missing something, please advise.

Regards,

Hamid,

I think sketching out your SPI topology may help me.

The first thing I would do is confirm that the MSP430 can in fact have its SPISOMI and SPISIMO signals tied together.  Unless the peripheral is specifically designed to handle this arrangement, contention between SIMO and SOMI on the MSP could very well be your issue.

Note that I wouldn't expect to see anything until you've written something to your C2000 MCU's TX buffer.  Are you doing this?

[FYI: Based on my understanding of your system's needs, I don't believe 3-wire modes are appropriate.  The most common use-case when multiple slaves exists is to have the SPICLK, SPISIMO, and SPISOMI go to each slave.  You'd then bring along one extra GPIO to serve as the chip select for each of the MSP430s.  Therefore you would use (3 + 1*NumOfMSPs) GPIOs. This is what I would recommend doing in most instances.  If your MSPs will be connected to the C2000 via a connector (and therefore you want the connector to be as small as possible) or you don't know how many MSPs will be connected, then perhaps a setup where SPICLK, SPISIMO, SPISOMI are all shared and no STE/CS is used may be appropriate.  In this latter case you'd need to employ a defined packet with addressing embedded inside your MOSI packet.  You'll be trading off higher-speeds, less-complexity and more pins vs lower-speed, more-complexity and fewer pins]


Thank you,
Brett

SPISOMI and SPISIMO cannot be tied together and connect to a slave, unless some arbitration mechanism is used to ensure that master and slave donnot transmit together. I would suggest that u put a resistor e.g. 1K between the MO and MI on both sides. This will help u to to debug physically and check that Both master and slave donnot transmit simultaneously. U may use a osilloscope to actually see signal levels and judge if there is a conflict.

SPI is a contentionless bus, thus it will not tolerate a bus confilict, which is quite possible when u use 3 wires. The behaviour beyond a conflict depends upon the specific implementation in silicon and cannot be predicted, usually spi stops transmitting.

I would suggest that with resisters in place, u should be able to see and program ur slave, if it can be actually programmed into 3 wire mode and its OUT goes tristate. If not u will have to use some tristate buffer trick to isolate that.

I think 3 wire is not a standard spi interface, it is just a short implementation, Brett can u comment on it.

Regards

Jawwad

Jawwad,

See:
http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#Three-wire_serial_buses


Thank you,
Brett

Thanks Brett,

I have used SPI in various modes with various devices, including inter processor as well as memories, rf components etc. The wiki page is a good starting point, but it misses out that a half duplex mode must be supported by the slave device and can be configured by programing some registers. Otherwise, the slave will transmit when ever it receives a clock causing a conflict on Master Out. The Master usually stops transmitting immediately. This is common in all silicons that I used so far. 

Thus I now fairly believe that SPI is 4 wire, the 3 wire interface is a sort of customization of SPI. The silicon on almost all processors that I used including ARM, TI DSPs, Silab, Atmel etc. is full duplex and u cannot program it to half duplex the way typically an spi eeprom is.

Well as long as we understand the caveats of SPI, we can avoid the pitfalls.

Regards

Jawwad

Hi Bratt,

It looks like SPI device in 4-wire mode, will automatically de-energize/energize the SPISTE line during transmission and receive operation and software has no control over that control line.Therefore in 4-wire mode all 4 interfacing lines are used and none of them can be used as regular GPIO. then in this case the number of required line would be (4+1*Numof MSPs). Is this correct?

Regards,

Hamid,

Your question is more precisely one of the two below (I think).  I will answer both.

1) The SPI peripheral will generate the SPISTE signal, therefore I need reserve a GPIO for this.   Correct?

[BL] No, even though the SPI peripheral will generate the SPISTE signal it need not be output via a GPIO.  Each GPIO can be chosen to use various peripheral modes or GPIO mode.  This means the SPISTE signal will be generated but may only be a physical signal inside the MCU and never go external.  Because of this, you will only need to reserve/use (3+1*NumOfMSPs) pins/lines.

2) SPISTE seems to be generated by the C2000 and seems to be needed to communicate.  Why do you not count it? 

[BL] In addition to SPISIMO, SOMI, and CLK a fourth signal is commonly used to choose which slave device is being communicated to.  Occasionally, there is some timing requirement for this signal (the chip select signal or enable signal), but often there is not.  In the case of a C2000 master addressing MSP430 slaves I do not believe there should be any timing requirement on the chip select signal.  As a result, you wouldn't need to use SPISTE and can just use GPIOs to choose which slave is being communicated to.  The GPIOs would need to be software controlled, but the timings are likely not stringent.  As a result, (3+1*NumOfMSPs) is valid.

Thank you,
Brett

Hi Brett,

Thanks very much for your clarification. But Let me ask you this if I may.

Per your clarification then, if I configure my Piccolo's SPI as a 4-wire mode device.I still can configure and use the SPISTE pin as a GPIO pin during my initialization for slave selection process irrespective of its (SPISTE) internal dynamics during transmission (this confuses me a bit: internal dynamics of SPISTE signal has no effect on my configured pin GPIO software controlled selection signal). IS this correct?

Then in this case, can I use this SPISTE/GPIO pin as a way to synchronize the communication between the master and selected slave?

Also, in this case what is the benefit of using 3-wire mode, I can then always use SPI in 4-wire mode and configure its SPISTE as a GPIO for selection puposes. Would you please advise.

Thanks,

Brett,

in ref. to above discussion, I modified the InitSpiaGpio() routine in F2806x_Spi.c file in example code as:

GpioCtrlRegs.GPAMUX2.bit.GPIO19 = 0; // Configure GPIO19 as GPIO not SPIASTEA

Now when I run the image on the target, I do not see any Data being transmitted by the Piccolo to the the slaves, while when I revert the change to its original configuration as a SPISTEA signal. Piccolo transmits correct bytes to the slave MSP430.So it looks like SPI device does not transmit without the CS/control signal.

Regards,

Regards,