• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 263 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.

MCT8316A: NAKs always

Marcel van den Heuvel
Prodigy 235 points
Part Number: MCT8316A

Hello, 

I've stumbled upon a problem while enigneering a product using the MCT8316A. 

The device always NAKs every I2C byte. The product's software will try to write the control bytes, but even the target ID is NAK'd. 

Note that is used to work, but suddenly, the device started to NAK every request. 

This is the situation:

- MCT is powered with 17V PSU

- For testing purposes, I've removed the motor from the outputs

- I am using Fast mode I2C (400KHz) and verified the timing table of chapter 7.6 from the datasheet using an oscilloscope. 

- Fault output is high (device does not report a fault)

- SPEED/WAKE pin is driven high while trying to access the device, in case it "sleeps"

- DRVOFF pin is driven low

What I've tried:

- Powercycle 

- Every other address on the I2C bus 

- Reduce crosstalk between SDA and SCL bus 

- Measure all the voltages (AVDD, DVDD and FB_BK) which are all as expected

- Replace the MCT chip 

But the problem persists. What bugs me is that after replacing the MCT the problem is still there. That would suggest there is an other issue going on, but looking at the voltagelevels on the power pins, it all looks good. 

And now, I am out of ideas. 

Thanks for any reply!

  • 0
    TI__Intellectual 1240 points

    Hi Marcel,

    Thank you for the detailed description. May you send an image of the scope capture of the waveforms?

    An issue may be that you need a 100 us delay between each byte. This, as well as other I2C specifications, are covered in the datasheet in section 8.6.2. You mentioned checking Section 7.6 of the datasheet, but you could also look over that section.

    Best,

    Hong

  • +1 in reply to Hong Khor
    Prodigy 235 points

    Hello Hong,

    I've got the MCT to respond again. My guess is that with the default configuration from the EEPROM, and the motor of this application it was too busy to respond on the I2C bus. 

    About the 100us delay; it is implemented, but if the MCT does not even acknowledge the very first byte is is sent, something else is the problem. 

    I have fixed this to pull the DRVOFF pin high, to disable the output. Then; when pulling the WAKE pin I can communicate to the device again. 

    Thanks anyway!

    Marcel

  • 0 in reply to Marcel van den Heuvel
    TI__Intellectual 1240 points

    Hi Marcel,

    Great! Thanks for the update.

    Best,

    Hong