• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 78 subscribers
  • Views 10540 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SPI - Multi Master Mode

Srikant Avasarala
Prodigy 110 points
Other Parts Discussed in Thread: MSP430FG4618

Hi ,

Can anyone please tell how to use the USCI module in MSP430FG4618 in SPI mode as multi master , i.e. how to allocate the bus etc. I feel it has  got something to do with having the SPI in 4 pin mode where I have the UCxSTE signal but I am not able to figure out how . Can someone please help ....

Also , in the 3 pin mode , I can have only one master and many slaves right? or I can have a multi-master here also ?

Thanks

Srikant Avasarala

  • 0
    Guru 227245 points

    in 4 pin mode, STE is used to disable the signal output immediately.
    Anyone pulling STE will immediately disable the data output.
    If the target was master, clocking output is also disabled and the internal states are reset. The software won't notice this, so the STE signal should be routed to an interrupt capable port pin too.
    If the target was slave, only the output is disabled and the reception of the clock signal. Once STE is released, the transfer will continue (even in the middle of a bit) as if there was no interrupt. To reset the transfer, SWRST needs to be set manually. To do so, teh STE state change needs to be detected by an interrupt capable port pin and the IST has to handle this condition.

    So how does this work for multi-master? Basically, one master will pull the trigger on the other one by software (using a GPIO pin), to ensure that it won't interrupt. It's well possible that they will disable each other.

    So teh STE pin is rather a 'shut up' line than anything that helps to coordinate multiple masters. Thsi task is left to the software.

  • 0 in reply to Jens-Michael Gross
    Prodigy 110 points

    Hi Jens-Michael Gross,

    Thanks for the reply .

    Jens-Michael Gross said:

     The software won't notice this, so the STE signal should be routed to an interrupt capable port pin too.

     

     )

     

    Could you please elabore ......

    Also....

    I have the following configuration :

     

    Here I want to have 2 masters - master 1 and master 2 . I have made the connections in the slave independant mode for the master 1 . I want to do the same for master 2 also to control the 3 slaves : slave0, slave 1 and slave 2 . My doubts are :

    1.)How can i connect the CS0 of master 2 and CS0 of master 1 to the same R pin of any slave . Wont it be shorting CS0 of master 1 and CS0 of master2 ?

    2.)The STE of both the masters should be connected so that one master may  be able to "shut up " the second master . Correct?

    3.) Can a slave "shut up " the master ? If so in which situation should I do that ?

    4.) Suppose I have such kind of a situation : The slaves are smoke detectors . Slave 0  has detected smoke and wants to talk to the master . But the master is talking to slave 1 now and then slave 2 . Is there any way by which slave 0 can tell the master to stop talking to the other slaves and service it instead ? (by using the STE here if possible. but then if i have  multiple slaves then I will want to connect the STE of master with all the slaves as any slave can detect the smoke . how would the master know which slave has detected the smoke in this case?

     

    Thanks,

    Srikant Avasarala

     

  • 0 in reply to Srikant Avasarala
    Guru 227245 points

    Srikant Avasarala said:
    How can i connect the CS0 of master 2 and CS0 of master 1 to the same R pin of any slave . Wont it be shorting CS0 of master 1 and CS0 of master2 ?

    It would. But there's a trick to circumvent it (besides using an OR or AND gate):

    Don't switch the output state between high and low, swich between low output and input and add a n external pullup. This way, the master will only drive the pin low but never high. And when both are not driving it low, the pullup will pull it high.

    Srikant Avasarala said:
    The STE of both the masters should be connected so that one master may  be able to "shut up " the second master . Correct?

    Not connected, but Master 1 should control STE (and an additional, best case interrupt-capable, port pin) of Master 2 with a normal port pin and vice versa. Interrupt-capable, so that the master will be notified if he's shut-up or released by the other master, so he won't initiate a transfer on its own.

    Unfortunately, tehre's no way to determine the current state of the STE pin (I'm not sure whether you can read the port pin and get the current state - on some MSPs it would work, on others the GPIO input is latchend when the module usage is enabled), and the SPI module won't generate an interrupt on a pin change. Which makes SPI multi-master or SPI slave more difficult than it ahs to be. and SPI slave is already the most complicated thing because of the timing requirements.

    Srikant Avasarala said:
    Can a slave "shut up " the master ? If so in which situation should I do that ?

    In theory, it could, but this would be not covered by the SPI specification. (multi-master isn't covered too, afaik). The STE pin is a nice addition to help shutting down the device output immediately, which would take quite some time if it had to be done by software. Time that isn't available by the standard.
    So no, no slave should shut down the master for any reason. That's why it is a slave and no master itself :)
    If a slave has nothing to say anymore or is busy, it should respond with a busy value. See the SD/MMC card specification how idle states and delays are handled: master sends a command and polls the slave until it gets a non-FF status byte. (on MSP, being addressed as slave and not having put anything into TXBUF will result in an FF byte to be sent. Since SPI always receives a bit on a clock pulse, even a non.responding slave will send an FF. There is no way to tell the difference.

    Srikant Avasarala said:
    Is there any way by which slave 0 can tell the master to stop talking to the other slaves and service it instead ?

    Some SPI devices have an interrupt signal output for this purpose. If you connect it to an interrupt-capable port pin (either Port 1/2 GPIO or a timers CCR  unit in captur mode), you'll get an interrupt when this happens. The firmware can then shut down the current transmission and establish a new one to the interrupt source. Or reorder the polling priorities or whatever.

    Srikant Avasarala said:
    how would the master know which slave has detected the smoke in this case?

    Silencing the master by pullign STE will only silence the physical signal output of th emaster. It won't tell the masters firmware that anything happened. And even if, there is no way to tell who has pulled the STE pin if there are multiple sources connected. If you use a dedicated interrupt pin instead, it's obvious who pulled the trigger. Or if you group them toghether, you have to establish a connection to each slave and poll a status info. If available in the slave protocol. Which of course is slow.

    Since the slave is always sending something back while the master is sending something, the slave could always put a status byte into TXBUF as default after being selected, while it is waiting for the first master command byte to arrive. No need to send a 'read status' command then. But that is part of the slave implementation and data protocol and has nothing to do with SPI itself.

    By the way, why did you label the pins R (reset)? Do you keep the slaves in reset state untiul you want something? THis is not a good idea because most devices have a long startup time. Usually, they have a separate chip select input. Use this for the selection of the slave. If you want to reset them too, group all reset pins together and use a separate GPIO pin. And only reset them if required, e.g. at system statrup or if a failure is detected (no response). Don't keep them in reset state just to shut them up.

**Attention** This is a public forum