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 on F2013/ FG4618 Experimenter's Board; stuck state machine

Hello,

I've programmed the state machine to the following algorithm for I2C communication:

 


state 0: Generate start condition & send address to slave. Go to state 1.

state 1: Receive address Ack/ Nack bit. Go to state 2.

state 2: Process address Ack/ Nack & handle data TX, i.e.

            if Nack received, send stop(go to state 5), else
            if Ack received, TX data to slave(go to state 3)

state 3: Receive data Ack/ Nack bit (go to state 4)

state 4: Process data Ack/ Nack & send stop, i.e.

            if Nack received, do nothing, else
            if Ack received send stop (go to state 5)

state 5: Generate Stop condition

 

I wrote:

 

    I2C_state = 0;
 
   USICTL1 |= USIIFG;
   

      do
    _BIS_SR(GIE|LPM0_bits);
   while (I2C_state >= 0);

 

But the state machine is stuck on state 1.

 

I wonder why!

Krishna.

 

 

 

  • Krishna Thallapaka said:
    I wonder why!

    I do too. And unless I can see how you initialize the I2C and what your ISR state machine really does (not what it is intended to do), we will keep wondering.

    I'm not an USI expert (just USCI, which is different). but I think you can write the first byte right after start. If the slave ACKs, sending immediately starts (and TXBUF is ready for the second byte), else you'll get the NACK flagged and the content in TXBUF is discarded at the next start.

    Also, I think that you can group some of the states as they don't need a waiting delay in between. Using different states is only necessary if there is a deleay between them and you want to leave the current function 8waiting for a condition or a timeout or such) and later enter it. Else a state machine has no use except being one (for theoretical work).

    e.g. either your state 3 is a transition and not a state, or state 3 and 4 are the same state (or do you mean 'waiting for ACK/NACK' instead of 'receiving'? then this is a state, of course). Also, processing of the ACK/NAK and acting on it is the same state too. Generating the stop belongs to state 4 and state 5 would be idle state (waiting for a trigger for restart)

    Anyway, your state diagram sufficiently describes the process. But does your code implement it properly?

**Attention** This is a public forum