• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 78 subscribers
  • Views 889 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.

UCB0 I2C Slave Issue on MSP430F5308

Mayuresh Manjrekar
Prodigy 100 points
Other Parts Discussed in Thread: MSP430F5308

Hi,

We are developing a product in which there are up to 10 MSP430F5308 boards connected as slaves on a single I2C bus. The I2C master is a STM32F207 ARM MCU. Every MSP slave board has an I2C repeater on it, so effectively there is a repeater before every slave on the bus. The firmware for the MSP is developed in C using CCSv5. The I2C slave initialization and I2C ISR is same as given in the example programs of CCS.

Now the problem we are facing is that suddenly in the middle of communication (it occurs very randomly, no fixed pattern / time) the master begins to see the I2C bus busy (the busy bit in the STM becomes set). From this point onwards the STM32 does not begin any I2C transfer since it will not do so if the busy bit is set. Naturally the slave will also not receive anything and hence it becomes a deadlock.

Now comes the strange part. Our initial assumption was that STM32 I2C peripheral / code might be causing this issue. But during debugging, we did a hardware reset of the STM32 MCU, while not touch the MSP slaves. This caused the STM32 to reset and begin program execution from the begining, yet again it saw the bus busy and did no communication. Now when we reset the slaves, keeping the STM32 untouched, it does not see the bus busy anymore and starts communication.

Our problem is that we are not able to figure out what exactly is happening during communication that the STM32 starts seeing the bus busy. Also we are not able to figure out if it is a firmware / hardware issue. If things dont get sorted out soon, the company would take a decision to replace the I2C bus with a much more expensive but robust CAN and replace MSP slaves with some other microcontroller with built in CAN (preferably other STM part).

Can someone in the forum shed some light on the issue. Has anyone seen similar behaviour before?

Thanks in advance!

- Mayuresh  

  • 0
    Guru 227245 points

    Two things indicate a ‘bus busy’:
    1) A high->low transition of SDA while SCL is high. This is a start condition and the master (if it isn’t its own start) should wait until it sees a stop condition on the bus.
    2) a low SCL line. Since SCL is active-low, this indicates an ongoing transmission by a different master.

     While usually only the master gives the clock (and therefore case 2 seems odd when there is only oen master), a slave can also hold SCL low. Thi sis called ‘clock stretching’ and ‘holds’ the current transmission until the slave is able to provide or receive the next bit.
    Some slaves offer the ‘hold master’ feature: when being addressed but busy, they hold the SCL line low on the ACK bit of the start byte until they are ready. If there is only one slave, then this is the fastest way to get the result once the slave is ready.
    The MSP USCI module, however, also does this during data transfer. IF a byte was received but not yet read form RXBUF, the USCI will hold SCL low on the 7th bit of the next byte (because after the 8th, the data would overwrite the content of RXBUF)
    When transmitting, when nothing is written to TXBUF, the USCI will also hold SCL low until the code writes something to send to TXBUF.

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

    We do observe clock stretching at the stop condition of every packet transfer on the bus. During normal operation, the STM32 would be sending a request packet of 8 bytes over the bus and the slave would respond with a response packet of 8 bytes and this goes on. The delay between two consecutive requests 500ms, which is quite large and should not cause an issue i hope. But yesterday we hooked up a scope and observed the packets and saw that the clock was being stretched at the end of the frame at the stop condition. Please see the images one is showing normal clock frequency (OFFtime = ~4.5us) while the other one shows the clock line stretched during the stop condition (OFFtime = ~6us). I dont know if 1.5us difference is going to matter.

    The USCI module behaviour that you have stated is given in the errata sheet as well i think. They have given some workaround for it which I guess is not implemented in the I2C example codes for the chip. I will implement them and see if it helps.

**Attention** This is a public forum