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.

I2C Slave: Detecting Arbitration Lost

Other Parts Discussed in Thread: MSP430G2231

Hi there,

I am working with MSP430G2231. I am using USI module as I2C Slave. I need to detect if a slave lost arbitration while transferring data. I know it is possible to do so in Master mode using the USIAL flag. However, this flag is disabled if I am in Slave mode (USIMST=0) as can be seen from the User Guide's USI Block Diagram for I2C. Is there a hack I can use to enable USIAL flag in Slave mode? How accurate is the schematic on the User Guide for executing hacks?

 

Thanks,

Nihad

  • Nihad,

    Maybe you can help me understand the question better?

    The concept of losing arbitration applies only to masters on the I2C bus. Arbitration implies: an I2C master having to fight for control of the bus with another master.

    According to the I2C spec: "If two or more masters try to put information onto the bus, the first to produce a ‘one’ when the other produces a ‘zero’ will lose the arbitration".

    So I'm not sure why an I2C slave would be required to detect arbitration?

    I don't think the UG supports 'hacks'. It only describes the intended usage of a module.

    Regards,

    Priya

     

  • Nihad Nasim said:
    I need to detect if a slave lost arbitration while transferring data

    That's simple: you can safely assume that you didn't lose arbitration during data transfer. During data transfer, master and addressed slave own the bus and no other master or slave will try to send anything.

    Nihad Nasim said:
    Is there a hack I can use to enable USIAL flag in Slave mode

    YOu cannot detect losing something you never had and will never have.

    Bus arbitration is something that happens when a master starts a connection and another master does the same at the same moment. Then one will detect that it lost arbitration to a different master - depending on which of them was the first to send a '0' data while the loser tried to send '1'.
    If arbitration is lost, then it happens during addressing the slave and not during data transfer.

    A slave (this is why it is a slave) cannot ever be the master of the bus or lose arbitration. And there's no way for the slave to detect that one of the (possibly many) masters on the bus lost arbitration, as the slave cannot know which master tried to send what.

    The physical and logical structure of I2C ensure that the slave seletion of the 'winning' master is undisturbed by any arbitration conflict. Either both masters address the same slave at the same time (then it makes no difference) or they address different ones, then the physical structure ensures that only the address with the lower value will appear on the bus (and the other master will detect this and get silent). For the slaves, there is never any conflict visible.

  • Thank you for your replies. Bus arbitration is not required for a slave is partly true for I2C. However, I am developing a variant of I2C called SMBus where I need to dynamically allocate addresses to slaves. In that case, there is a command called GetUDID issued by a master where each slave tries to send their unique UDID. Then, the slave that tries to send a 0 over a 1 wins arbitration. That way you will ensure you are talking to one slave threby assigning them a dynamic address. Anyhow, I was able to successfully implement a hack!! I was doing the right thing but I forgot the fact that start condition interrupt does not happen in master mode (I enabled master mode as part of the hack). So, I had to enable and disable master mode at unique points in the state machine to make it work. Thanks for your help though.

  • Okay, this SMbus arbitration is of course a problem. It extends I2C in a way that is not fully compliant to the original I2C specs. And I see that for SMBus arbitration check is needed for slaves too, as there is a chance that more than one slave is talking at the same time.

    Using master mode to detect arbitration isn't that easy too, since then the master will try to do the clocking (it's necessary to route the CLK signal to the USCI clock input, so the 'master' generated clock will match that of the real master - at the same time disabling the ability to detect clock stretching). Also, the virtual master will send a start condition on the bus (which shouldn't be allowed)

    It's really tricky.
    I'd go for a software-implemented I2C that kicks in when the addressing command is received and handles this one case.

**Attention** This is a public forum