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.

MCT8316A: I2C issue with motor controller, NACK with some devices.

Part Number: MCT8316A

Hi Texas Instruments team

We have got an application with more than one motor using MCT8316A via I2C (resistive buck used), the application have one microcontroller SAMV71Q21 and as the address can not be modified, we use a I2C translator to go from 0x51 to 0x00, however the answer has been NACK, for this reason by using the same bus I included debug devices (in red), one additional master identified as master 2 and one slave identified 0x03.

By using the master 2 (debug), I send information , byte 0x00, to address 0x51 and I received ACK from Motor A, please look the graph, you are able to see how works translation from 0x51 to 0x00, with no issues.

Yellow=SLC bus

Cian=SDA bus

Blue= SCL after translator

Pink=SDA after translator

f=50.015Khz

ACK received

However by using the master 1 which is my main microcontroller, I received NACK, no answer from motor controller when is required by master 1 (f=49.55Khz).

I tried master 1 to talk with Slave 0x03 (f=49.55Khz) and I received ACK so master 1 can speak I2C, so essentially the problem is when I try to talk with Motor A and master 1.

I appreciate if you could help us with the following questions:

1. Why the motor controller is ACK with one microcontroller and not with the other one even connected to same I2C bus?

2. Could the difference in the frequency (f=50.015Khz success communication) and (f=49.55Khz fail communication), the issue?

3. What is the cause of this behavior, what we need to modify to receive ACK from Motor A when using the master 1.

Let me know if additional information is required.

Thanks.

  • Hi Carlos,

    Few questions,

    1. CRO signal color after translator (Pink is SCL , Blue is SDA)

    2. Post translator SDA signal timing is not matching with pre translator, please re check if I am seeing the signal not correctly. Also, post translator SDA is not driven properly. With debugger 2  I can see signal but not very convincing and with original master it is even poor.  Can you check liek pull up values? What is pullup pre and post translator used?

    Thanks and Best Regards,

    Venkatadri S

  • Hi Venkatadari

    Thanks yo so much for your support below please find the answers in blue:

    1. CRO signal color after translator (Pink is SCL , Blue is SDA)

    Yes, that's correct, pink is SCL and blue is SDA after translator. 

    2. Post translator SDA signal timing is not matching with pre translator, please re check if I am seeing the signal not correctly.

    SDA not match because the translator function, before translator the address is 0x51and after translator the address is 0x00, so is expected a different SDA as the motor only accepts 0x00 address, however you saw, both SCL before and after translator match (is not expected to have a different SCL)

    Also, post translator SDA is not driven properly. With debugger 2  I can see signal but not very convincing and with original master it is even poor.  Can you check liek pull up values? What is pullup pre and post translator used?

    Pullup pre translator= 5.1 kOhm

    Pullup post translator= 5.1 kOhm

    Both sides are connected to same Vcc-GND.

    Its also relevant to share the motor driver receiver with debug2 was ACK as the first image, however with master 1 remains NACK.

    Any advice or feedback on this side Venkatadari? please let me know.

  • Dear Texas Instrument team.

    We discovered a software issue with receive command, which don't allow us to receive ACK from motor driver, as you can see the debug 2, transmited info to the motor controller but the master 1 was receiving information, so when we use the transmit command from master 1 was possible to receive ACK, the problem seems to be related to a non standard I2C format used by the motor controller because require a specific structure, so we will modify the software in order to properly read the receive info.

    We can close the ticket.

    In any case thanks for your support.