TCA6424A: Figure24 and behavior in case of unexpected command receive

Hello Hirotaka-San,

"2. After that, incorrect Command data is received, TCA6424A sends NACK to master because of incorrect data.
3. After that, correct Command data is received again, does TCA6424A send ACK to master?
    Or, should we turn to initial condtion using dummy SCL signals?"

You mean if you send something like 0xAA in step 2 for the command byte and then instead of doing a stop condition and starting again you send another byte such as 0x8C?

Ideally what you should do is if you see a NACK when you send the wrong command byte is to do a stop condition and then do a start condition and resend the correct command byte (after sending the device address again).

"So, which is correct?
-Real timely output changes.
-After stop condtion, output changes.?"

I have not yet confirmed this in our lab yet but speaking with one of our senior engineer, he informed me that our devices do not actually update their registers until a stop condition is done. If the customer is saying that they are seeing the output change every time the device ACKs then I would say the output changes with the ACKs. I can verify this later. It could be possible our senior engineer may be correlating the delayed output of our I2C switches with the IO expanders. (I know that our switches do not change channels until a stop condition occurs.) The IO expanders may not have this issue.

I'll get back to you on this.

Thanks,

-Bobby

Bobby san

Thank you so much for you confirmation.

We got that IO expanders will reflect their values at an ACK condition.

We have additional questions about followings;
"2. After that, incorrect Command data is received, TCA6424A sends NACK to master because of incorrect data.
"3. After that, correct Command data is received again, does TCA6424A send ACK to master?
    Or, should we turn to initial condtion using dummy SCL signals?"

You mean if you send something like 0xAA in step 2 for the command byte and then instead of doing a stop condition and starting again you send another byte such as 0x8C?
Ideally what you should do is if you see a NACK when you send the wrong command byte is to do a stop condition and then do a start condition and resend the correct command byte (after sending the device address again).
->OK, we understood that ideally recommendation operation is to do a stop condition and to do start condition and resend the correct command byte.
   In case of 0xAA(Incorrect command byte)->0x8c(Incorrect command byte), could you let us know follows?
   -Command 0xAA is ignored, and then does command 0x8c reflect? After the device receives 0x8c, does the device return ACK to the master?
   -What does the state machine?(We guess that it is difficult to imagine,,,,)

We appreciate your help always.

Kind regards,

Hirotaka Matsumoto

Bobby san

We are sorry to bother you, however if you have some give answer for our last update, could you let us know?

Kind regards,

Hirotaka Matsumoto

Bobby san

OK, we are wait for your update!
Thank you for your help!

Kind regards,

Hirotaka Matsumoto

Hey Hirotaka-san,

Bad news, I've tried to program my mcu to send the address+write-->(bad command: 0xFF) command-->data byte (0x00) and monitor what happens on the o-scope. I am able to see that the device ACKs for the address and write bit but then NACKs for the command byte. After that my mcu stops sending data because of the NACK, this seems like the mcu I2C library was programmed to stop communication to the slave if there was a NACK event from the slave.

I might be able to bit bang this myself but it would take me a bit of time to try to write the program for this. I may not have time to do this today.

Very sorry for this delay. I didn't think the I2C library would stop communication after the NACK.

-Bobby

Bobby san

OK, we are wait for your update.

Kind regards,

Hirotaka Matsumoto

Bobby san

Thank you so much for your cooperation always!

As the result of your confirmation;
-a bad command byte (0xFF) -> Slave sends to master NACK
-and then a correct command byte(0x02) ->  Slave sends to master NACK

As the conclusion, after receiving a bad command byte, next command byte was ignored.
Is this correct?

Kind regards,

Hirotaka Matsumoto

Bobby san

Thank you for your cooperation always!
OK, we got it!

Kind regards,

Hirotaka Matsumoto