• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 79 subscribers
  • Views 770 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.

MSP430F247: USCI30

mesotech
Prodigy 10 points
Part Number: MSP430F247


Hello! The problem is related to I2C error called USCI30.

I am using MSP430F247. If it was working as I2C

master receiver, the workaround for USCI30 was implemented

and working well. Now I have to use the microcontroller as slave receiver.

Implementing USCI30 workaround when slave receiver

rises the question: how does the slave know when it is the

last byte to read? We must read the last byte immediately,

NOT stretching the clock for 3 periods after 7th clock pulse.

All other bytes before the last need the clock to be stretched.

I have also tried to stretch all bytes including the last, but it made

the I2C traffic unstable.

The master receiver always knows how many bytes he wants to read

and can find when is the last byte. Slave receiver does not know

generally the total count of bytes that the master wants to transmit.

What do you suggest?

Best regards,

Jüri Sheffer.

  • 0
    TI__Guru 56685 points
    Hello Juri,

    There are two ways around this. First is using the first workaround for the erratum which is making sure you service the RX interrupt in a timely manner. this basically means as soon as you get the interrupt, you can get into the ISR and read the RXBUFF first (just after check for RXIFG). You have to guarantee this in every situation which means in various LPMs and if other ISRs are too long. The safer way to work around this erratum is the method you employed for the master code. For slave, you would need to be able to look up how many bytes to be sent to the master based on the first value sent (typically a command byte or register byte). Most commands have a set amount of return bytes expected in which you can use a byte counter to know when the last byte is being sent. An alternative to this is if you also control the master, you can do a simple protocal of send command, then how many bytes it expects back, then switch to reading from the slave.

**Attention** This is a public forum