• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 78 subscribers
  • Views 2218 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.

Manual Clock Stretching

Prakash Balagangatharan
Expert 2440 points
Other Parts Discussed in Thread: MSP430F5335

Hi,  

I am working in MSP430F5335 development bord. I am inplementing i2c protocol in this. I have some problems with checking the error condition of SCLLOW.  In user guide they would mention the UCSCLLOW bit is set at the time of slave pull the SCL line. I tried to make the scenario manually by connecting two MSP430 board  one with i2c implemented code and another board with GPIO pins direction as output and pin status as low i.e.  

 P1DIR = 0xFF;  P1OUT = 0x00;

 Can anyone knows how to make Manually clock Stretching.    Thanks in advance

  • 0
    TI__Guru 71301 points

    Hi Prakash,

    So it sounds like you want to have a second MSP430 that is trying to simulate a slave device stretching the clock, correct - so it needs to intentionally cause clock stretching?

    You could configure your 2nd MSP as an I2C Slave, then have the master request it to transmit data (address it with the slave address for the 2nd MSP with the R/W bit set). At this point, the slave MSP will be in slave transmitter mode, and the UCBxTXIFG flag will be set. Normally, you would want to have an interrupt service routine immediately fill the UCBxTXBUF at this point so that the slave can start sending data back to the master. However, if you do not fill the UCBxTXBUF, then the SCL clock line will be held low (clock stretching).

    So you could simply make your slave code do something to intentionally not fill the TX buffer, or to make it have some very long delay before it fills the TX buffer (delay cycles, etc).

    There's more information on I2C Slave Transmitter mode and when SCL will get held low in the user's guide www.ti.com/lit/pdf/slau208 section 36.3.4.1.1.

    Hope this helps,

    Katie

  • 0 in reply to Katie Pier
    Expert 2440 points

    Hi Katie,

    Thanks for your information. As per your explanation i can able to make the Clock Stretching senario.Here i am facing one problem in my software. Actually i have implemented like as after start i am checking NACKIFG then i am checking SCLLOW is it correct?

    In My hardware that SCLLOW bit is set, but in my code if i put some delay before that SCLLOW error handling is working fine, but if i put delay my normal operation read from slave is not working. i have given the proto code of my implementation 

    UCBCTRL = UCTXSTT;

    while(NACKIFG == 1)

    {

     NACK error set;

    }

    for(i=0; i<Dealy; i++);  //if this delay is not there SCLLOW  not works, if delay put means normal functions not works

    while(SCLLOW == 1)

    {

    SCLLOW error;

    }

    read operations;

     can you help me to understand how to handle this error?

    Thnaks in advance

  • 0 in reply to Prakash Balagangatharan
    TI__Guru 71301 points

    Hi Prakash,

    I think I need to back up a step and better understand what you are trying to do with the SCLLOW bit.

    If the slave is stretching the clock, that is not necessarily an error at all - it just means the slave is needing more time - it is even a part of the I2C standard, and MSP430 masters allow for slaves to use clock stretching and support this feature. You would be able to just wait for the IFG for the slave's response and don't even need to check the SCLLOW flag.

    However, perhaps you are concerned or having an issue where the slave is stretching the clock for a very long time and never actually responding (if slave has hung up for some reason)? If this is the case, then you might decide to implement some sort of timeout for if the clock is being stretched by the slave more than a certain period of time (this is even a feature of some I2C based protocols like SMBUS and PMBUS). A timeout like this would probably be implemented by starting a timer while waiting to get the response from the slave. If the interrupt for the slave response comes in, then stop the timer. If the timer times out and you get that interrupt before ever getting a response from the slave, then you could say you have hit your timeout and do whatever error handling you want (resetting your slave, resetting the USCI on the MSP, etc) - that part will depend on your system. As a note, devices with the eUSCI module (like FR5969 or F6736) have some built in support for SMBUS timeout functionality.

    Regards,

    Katie

  • 0 in reply to Prakash Balagangatharan
    Guru 227245 points

    Clock stretching can happen all the time. Not only after the start byte.

    However, manual clock stretching is not required at all, except if you have some very special reason.

    In slave transmit mode, the USCI won’t send the ACK (and hold SCL low) until you write something to TXBUF. So if you don’t do anything when the TX interrupt comes, then the clock will be stretched automatically. Same for any future byte: if you don’t write to TXBUF (and don’t set UCTXNACK), the USCI will hold SCL low until you do.
    In slave receive mode, the slave will ACK automatically, and start receiving. However, if you don’t read the first received byte, the USCI will hold SCL low on the 7th bit of the next byte, until you read RXBUF. Again, no manual stretching required.
    checking SCLLOW makes no sense at all in slave mode.

    For the master side, this too is handled automatically. SCLLOW is only there to notify you that the I2C is currently not progressing. (it may even happen if your pull-ups are too weak and after releasing SCL, it takes some time to rise, so the master will detect SCLLOW for some time, until the pull-up has done its work. However, in any case, the master will properly handle this situation in hardware.

  • 0 in reply to Katie Pier
    Expert 2440 points

    Thanks Katie,

    Is there any logic/formula available to find how long the timer will run to create interrupt to indicates the clock is low? i.e how do we calculate the timeout counter value? Is it depends one the i2c speed? Whether it will vary for slave to slave? Because i am not familiar with SMBUS and PMBUS protocols.

    Thanks in advance

  • 0 in reply to Prakash Balagangatharan
    TI__Guru 71301 points

    Hi Prakash,

    A timeout is not something that you are required to implement, it was just a suggestion if what you're really trying to do is detect a "hung up" slave device. If you are simply implementing your own communication protocol on I2C, a timeout could depend entirely on your application - you could choose it to be anything. Ideally you'd figure out how long your slave would normally take to respond worst case and take that into consideration, but it would be entirely up to you.

    If you were implementing SMBUS or PMBUS (but it sounds like you are not) those have a timeout specified as part of their spec, and a max time before the device must respond - that is in the protocol spec for these standard protocols. But if you aren't using these you don't need to worry about that.

    Regards,

    Katie

  • 0 in reply to Katie Pier
    Guru 227245 points

    It should be added that, if a slave is holding SCL low, there is no way through the bus to stop it from doing this. The I2C bus is stalled an inoperable until the slave releases SCL again.

    So you can either wait, or (if this is possible by the hardware) reset the slave, e.g. by shutting its supply voltage down, if possible.
    The only other alternative would be to accept that the bus is stalled and the slave is inaccessible and signal this to the user as an error situation.
    Note that SCLLOW will also be triggered if there are no pull-ups on the SCL (and SDA) line or the pull-up voltage is low. Or there is no common GND for master, slave and pull-up voltage. After all, I2C is a two-wire interface but requires three wires (SDA, SCL and GND)

  • 0 in reply to Prakash Balagangatharan
    Guru 227245 points

    Prakash Balagangatharan said:
    Is there any logic/formula available to find how long the timer will run to create interrupt to indicates the clock is low?

    Minimum I2C clock frequency is 0Hz. :)

    However, as master, you know your clock speed, and you know the time it takes to complete a clock cycle (and therefore send or receive a byte: 9 bit since last, including ACK). If it takes longer until next TX/RX interrupt than this, then likely clock stretching has taken place. Which might be caused by the master itself. E.g. the RX/TX ISR wasn’t called because another ISR was busy or interrupts were disabled. In this case, the timer may have expired and the timer interrupt may execute before the (also pending) RX/TX ISR is called to tell that all is well. This needs to be checked in the timer ISR.

    But, as I said, when the bus is stalled by a slave, you cannot change this. You can only detect that your communication failed and the bus is stalled, and be content with it.
    Imagine hopping down stairs in the dark. You know how long it takes before you land on the next stair. However, if you notice that it didn’t happen (timeout), all you can do is to prepare for the impact, not knowing when it will happen (or if at all).

**Attention** This is a public forum