• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 34 subscribers
  • Views 590 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

PCA9544A: Multi-Master Repeated Start

Johann Johann
Prodigy 100 points
Part Number: PCA9544A

I have looked at I2C and caveats with multiple masters and a question concerning the multi-master compatibility of I2C switches.
The PCA9544 datasheet states on p. 13 that:
When a channel is selected, the channel becomes active after a stop condition has been placed on the I2C bus.
This ensures that all SCn/SDn lines are in a high state when the channel is made active,so that no false conditions are generated at the time of connection.

This makes sense, however it also states:

"A stop condition always must occur right after the acknowledge cycle."

The intended sequence seems to be
(START) (Slave Addr) (Write) (ACK) (New channel config) (ACK) (STOP)

I tried to change the active channel of the switch, but followed by a repeated start instead e.g.
(START) (Slave Addr) (Write) (ACK) (New channel config) (ACK) (Repeated Start) (More transactions to other devices) (STOP)

It seems like the switch ignores the new channel configuration and keeps its previous setting. The transactions following the repeated start are therefore send over the wrong bus.
Using separate transmissions with a stop seems to be no problem in a single master configuration.
With multiple masters however, the repeated start is the only method to ensure that the transfer is carried out as intended.

A small example with

  • master 1 wants to read device X on switch channel 1
  • master 2 wants to read device Y on switch channel 2

An unwanted outcome of this might be

  1. master 1 reconfigures the switch to connect channel 1, transmission ends with Stop
  2. master 2 takes over the bus and reconfigures the switch to connect channel 2 and disconnect channel 1
  3. master 1 reads device X. If the address is occupied on channel 2 as well, master 1 doesn't even realize its the wrong device.
  4. master 2 reads the correct device Y without error.

As far as i understood it, the repeated start is the only method to avoid (rare) situations like this.
Without it, the switches are not 100% safe to use on a bus with multiple masters.
The switch addresses contain the maximum of 1's, so access to other devices should most of the time win the arbitration process.
I doubt that there isn't a device within the same address range of 0x70-0x77.
Other devices aside, what about cascading multiple switches to interface 4 x 4 branches instead of 4?

My questions:
How to use (cascaded) I2C switches on a multi-master bus?
Is it somehow possible to use the switches with a repeated start or am i missing something and this is not necessary?
Why is an immediate stop mandatory and the repeated start not usable?

  • 0
    TI__Guru 62920 points

    Hi Johann,

    We are looking into this and will get back to you later today.

    Regards,
    Max

  • 0
    TI__Guru 73891 points

    Hey Johann,

    "Is it somehow possible to use the switches with a repeated start or am i missing something and this is not necessary?"

    For our devices, if you are configuring the device to enable/disable channels, then you should not use a repeat start condition. (you can use it if you want to talk to another slave which is not one of our I2C switches).

    "Why is an immediate stop mandatory and the repeated start not usable?"

    The device's state machine was meant to enable the channels of the switch after it sees a stop condition. This was how the switch was designed from a silicon standpoint.

    "How to use (cascaded) I2C switches on a multi-master bus?"

    You just need to keep in mind that I2C switches typically use a pass FET architecture so you can treat them as a 'short' when the channel is enabled. This means if you have a bunch of switches in series/parallel and channels enabled, you also have a bunch of pull up resistors on each channel which are in parallel if we say the pass FET is a short when the channel is enabled. Just make sure that the IoL you see due to the parallel pull up resistors doesn't become larger than the I2C slave/master can handle (our device's pass FET current as well).

    I believe we have a tool released online to kind of construct something like this.

    ^It will essentially help you to select pull up resistors and checks to see if you violate any I2C buffer rules and provides fixes/alternatives.

    One solution I can think for your situation may be to put a master on one of the secondary channels, this would mean that the master on the secondary channel can only communicate to other devices outside of that channel through the secondary channel (which can be enabled and disabled by your other master).

    A second idea to prevent the second master from taking control of the bus while you have a stop condition is to force the I2C address of the I2C switch to change (dynamic addressing) right before the stop condition which would cause the other master to see a NACK what happens next would depend on software/code of what the master should do if he sees a NACK.

    http://www.ti.com/lit/an/scaa137/scaa137.pdf
    Dynamic addressing for I2C ^

    -Bobby

  • 0 in reply to BOBBY
    Prodigy 100 points

    Thank you very much for your detailed answer.

    if i understood you correctly, the switches require the stop to change state and because of this other methods have to be devised for multi-master operation.
    The application report about dynamic addressing is quite interesting, but we have to interface modules that have already been made and can't be modified.
    Our system involves 3 layers of switches to access all branches and we will settle for a hardware based solution (i2c bus arbiter) to allow multiple masters to operate on it.



  • 0 in reply to Johann Johann
    TI__Guru 73891 points

    Hey Johann,

    Johann Johann said:

    Thank you very much for your detailed answer.

    if i understood you correctly, the switches require the stop to change state and because of this other methods have to be devised for multi-master operation.

    This is correct.

    Our system involves 3 layers of switches to access all branches and we will settle for a hardware based solution (i2c bus arbiter) to allow multiple masters to operate on it.

    From what you described previously, this sounds like an appropriate solution. (Our I2C portfolio unfortunately does not have an I2C bus arbiter). The only other way I could think of would be to add more redundancy in the software (check to see if the I2C switch reads the correct value before writing to the secondary channels).

    Thanks,

    -Bobby

  • 0 in reply to BOBBY
    Prodigy 100 points

    Thank you very much.
    You really helped me a lot by sharing those details and pointing me to possible solutions.