Looking for MSP430G2553 4-wire SPI Comm. Code Examples

Kyle Engstrom said:

using 4-wire SPI Communications

Unlikely.
4-wire mode is used only when the MSP is slave or works in a multi-master environment.
What you count as 4th wire is the chip select signal that is not counted (there is one separate chip select signal for every slave on the bus, so 3-wire mode is actually 3+x wire mode). Chip select is completely under software control (the USCI doesn't know which slave you want to talk with). Any GPIO pin is suitable for this job. Pull this line low before you start sending/receiving and pull it high when you're done.

Edit: this answer applies when using the USCI in master mode. Which seems to be the case here, as few sensors play master.

Hello Jens-Michael!

Sorry for digging an old thread, but I have precisely the same problem right now.

I have seen a couple of replies from you in which you keep saying that 4-wire is used only in multi-master

environment. Could you develop a little bit?

In my case, let's say I have a motherboard which is master, then from this board, I have daughterboards

which are, say, slave_A and slave B. But they are sharing the same bus (MISO, MOSI, CLK) and I want to

communicate using A_CS (for selecting slave_A) and B_CS for selecting slave_B. In this case, there is

a single master, 2 slaves, 4 wires per slave (but 5 in total). Isn't this 4 wire SPI (although it's not a multi master)?

My idea was to use STE as a chip select.

Thanks,

Pascal

Pascal4275 said:

But they are sharing the same bus (MISO, MOSI, CLK) and I want to communicate using A_CS (for selecting slave_A) and B_CS for selecting slave_B. In this case, there is a single master, 2 slaves, 4 wires per slave (but 5 in total). Isn't this 4 wire SPI (although it's not a multi master)?

Your case is still "3-wire SPI Vulgaris" master mode because we don't count CS pins at all. 4-th wire in 4-wire mode of msp430 SPI is UCxSTE. Please refer to user's manual for more details.

Hello!

Thanks for your reply!

4-th wire in 4-wire mode of msp430 SPI is UCxSTE. Please refer to user's manual for more details.

Usually, I read the docs before coming here. And I found the problem: I was sending messages too fast.

I reduced the speed from 12Mbps to 8 Mbps (divider to 3 instead of 2 at 24 MHz clock) and now slave has

enough time to catch the bytes.

Now back to 4wires / 3 wires.

The CS (master side) is wired to the STE (slave side) of the SPI I'm using.

So just for my understanding:  do you mean that it's 3-wire at master side (because CS should not be counted)

and 4 wire at slave side (because STE is counted)?

I could verify that STE works fine (i.e. I can't get any interrupt at slave side when it's disabled and I can get

master's messages perfectly when it's enabled). Therefore it should work with 2 daughterboards, that was

the idea.

Pascal

Pascal4275 said:

So just for my understanding:  do you mean that it's 3-wire at master side (because CS should not be counted) and 4 wire at slave side (because STE is counted)?

It's still 3-wire mode of msp430 USCI peripheral with CS at slave side. Note that 4-wire mode of msp430 is specific mode of operation. You don't count used pins to see it's 4-wire mode but select it in USCI control register bits UCMODEx.

Hello!

You don't count pins to see it's 4-wire mode but select it in USCI control register bits UCMODEx.

Basically that's what I did at least at slave side (UCMODE_2 in my case, to be compliant with many device

with CS active low).

So to summarize, I'm working in 3 wires at master side (I leave default UCMODE) and in 4 wires at slave

side (I use UCMODE_2). Right?

Pascal

Pascal4275 said:

So to summarize, I'm working in 3 wires at master side (I leave default UCMODE) and in 4 wires at slave side (I use UCMODE_2). Right?

No. You don't use 4-wire mode if you don't have multi-master configuration.

Pascal4275 said:

I have seen a couple of replies from you in which you keep saying that 4-wire is used only in multi-masterenvironment. Could you develop a little bit?

Actually it's not the whole story.

4-Wire mode uses STE input signal (it is input only!) to gate the SOMI output in slave mode, disable the clock input and switch from master to slave mode (multi-master).

It is NOT used to select and de-select the slave, or to control any high-level control functions in slave mode. You can connect an incoming CS signal to STE to make the USCI silent immediately (so it won't clobber the bus) but you still need to handle it by software too. STE does not reset the shift register or reset your high-level protocol. It just gates the SOMI and SCLK pins. Which will of course prevent the interrupts (no clock) but requires additional action to reset the USCI for the next transmission.
Just using it without further software action based on the incoming CS will only work as long as there is no abnormal transfer termination. (e.g. if the master resets in the middle of a byte, you'll lose synchrony forever)

When you're single master, you don't need it nor can you use it. The USCI doesn't know how many slaves are on the bus and which one you want to talk to. So the chip select of the slave is to be done by your software and with as many separate I/O lines as there are slaves. This is why you always use 3-wire mode for single master, even though there is at least a 4th wire (CS). But maybe 5,6,200...

You can use the STE pin on master side as chip select. By using it as a normal GPIO pin (don't set its control bit is PxSEL).
If you use SPI of both, UASCIA and USCIB, the clock funciton of one USCI module will override the STE function of the other (both are then always 3-wire mode)

Hello!

Thanks for your reply!
In fact, what I have is a mother board and 2 or more daughter boards. Each of the
daughter boards uses a MSP430. So my idea was to configure the daughterboards as other
typical SPI devices in slave mode (clock comes from the motherboard) with CK, MOSI, MISO, CS.
So, let's call this 3 wires + CS.
Right now, I am using a single daughterboard for test. I have configured it as a slave
with STE used as CS. AndI use a GPIO on master side, wired to STE of the daughter board.
I could verify that if I do at master side (in pseudo code):

select();
spi_sendbyte('A');
deselect();
spi_sendbyte('B');

then A is received by slave, but not B.

I was looking for some kind of STE interrupt, and found out that there is none.
UCAxIE / UCBxIE have only receive and transmit interrupts. Right now, I'm using a
timer (a kind of watchdog made with a regular timer). I restart the timer after
each byte to prevent it to timeout. I'm assuming that one transfer should occur with
a (more or less) continuous flow of bytes. If timeout occurs, it means something
went wrong, so I put the device back to an idle state, reset counters, etc...
STE interrupt would be great.

Pascal

Pascal4275 said:

I was looking for some kind of STE interrupt

As JMG already explained - DONT"use STE input.

As CS input use just GPIO pin with pin interrupt. You shall know your slave timing - it's wake-up time. Then you will know how long master shall pause between asserting CS and SPI transfer.

Hello!

Thanks for your reply.

As JMG already explained - DONT"use STE input.

I understand that, but what I want to know is WHY. I tried and I already reported
above that the STE SPI mute works. Since it works I am just wondering why I should
not use it.

By the way, the table page 509 of SLAU208C indicates the effect on the slave (0 = active,
1 = inactive for UCMODE=10), so it seems that using STE on a slave is not an obscure
undocumented artefact but a well known feature.

I'm aware it does not reset anything when set to the idle state, and that's why
I was looking for some kind of STE interrupt to detect exceptional states (e.g. if I'm
waiting for 4 bytes and chip deselect happens before). It doesn't exist, so I'll choose
another solution, either with STE + timeout (currently working and under reliability
test) or GPIO interrupt (not tried yet). There would even be another solution: tie
together STE and a GPIO. STE would take care of the I/O enable, and GPIO (tied to STE)
would generate an interrupt that could in this case be considered as STE interrupt.

The drawback of GPIO only solution is that I have to do the mute by software
(unselect the USCI pins, make sure they are not in output so that they leave the
spi bus free, which would take some time) although it already exists with STE in
hardware (i.e. without any delay).
The drawback of GPIO + STE is that it would use 2 pins.

Pascal

Pascal4275 said:

the STE SPI mute works

Sure it does. Muting is thejob of STE. And only this, nothing more. Muting the slave as soon as the CS signal is de-asserted. For anything else (including resetting the USCI shift register or notifying the software), you'll need to detect CS by other means and doing it in software.

STE just freezes and mutes the slave. And only the slave. If the USCI is in master mode, it will turn it in slave mode.

Initially, the OP said that he's sending and receiving data to an inclinometer. Which implies that the MSP is master, not slave. And you wrote you have "precisely the same problem". And when you are single master, STE is not to be used.
If you are not master, then you don't have the same problem. :)

However, I already explained that STE in slave mode has its use and how it is to be used and how it is limited. And it seems you got it.

Yes, the (required) STE/GPIO combo requires two pins. And I agree that it would have been nice to have an STE interrupt, or maybe even a configuration set for STE (like resetting the USCI or not), but things are as they are.

You can live without STE (if the slave defines it takes 2 seconds after CS to finish operation and shutting down the SOMI driver, then the master has to know and to respect it), but likely less without the GPIO check.

Hello!

Thanks for your reply. I think this (and my experiments) has cleared all my
doubts on my current development.
The reason of all this mess is that I've been confused with 4-wire definition
(some say 4 wires is simply CK, MISO, MOSI, CS, some call this 3wires + CS
- and indeed CS is not really a signal - etc...) I have been confused with the
"STE in multimaster only", etc... So I was suspecting a weird problem that
might arise in a very regular case like what I am doing.

Anyway, to summarize the results: if some readers have the same doubts, there
are 2 things to remember:
1 - STE can be used as a chip select in slave mode to enable / mute devices
when there are multiple slaves so they don't talk together on the same line.
BUT:
2 - There is no hardware way to detect STE status changes, so this is a
no-seatbelts implementation and something has to be done to process exceptions,
either by hard (GPIO interrupt) or by soft (timeoout).

Pascal

I have been confused with the "STE in multimaster only"

This answer was in the scope of the thread. Which was master operation. But I understand that this isn't obvious for someone 'jumping in' without really digging into the thread. I've added a hint to my first answer