AM625SIP: MCT8329A

Hi William,

MCT8316 is not having clock stretch and hence we recommend 100uS delay between every bite.

Each byte is 8 bits data + 1 bit ack/nack, after this 100us delay before next byte transmission begins.

Thanks and Best Regards

Venkatadri S

Venkatadri:

Thank you for the response. I'd like just a bit more confirmation. Does the time between bytes apply only to writes from a master to the MCT8316/MCT8329a? I'm able modify my HAL driver (STM32) to add 100us delay on writes, but I'd like to confirm whether I need delays on bytes transmitted by the slave TI chip and received by master. That is difficult to manage as the MCT8329a is sending and controls that pace. Getting the first two bytes sent by the slave to have the break between bytes has been elusive, so I hope that slave sends don't require the 100us. After the first two bytes I'm able to delay the ACK and get the clock stopped gap of 100us.
My first effort with this code looks good as I ran my device that has three MCT8329a devices, all of which have exhibited the chip freeze, and I had no failures in 24 hours. I'd just like confirmation that this should be reliable and not fully rely on only my test results.

Hi William,

Master controls clock while transmitting and receiving. 

Every one-byte providem100us delay, slave can do clock stretching if slave need additional time.

Thanks and Best Regards

Venkatadri S

I don't understand "Every one-byte providem100us delay, slave can do clock stretching if slave need additional time." The MCT8329a is the slave and the problem is that part does not work in the MCT8329a

After reviewing TI Application Note SLLA662 – MARCH 2025, "How to Program I2C for MCx83xx Device Family" I understand that the 100us is only required for writes, not reads. I have implemented this for all address writes and data writes, leaving no transmitted byte without the 100us gap between bytes. I've also tried reducing the I2C clock to as low as 5kHz. The MCT8329a still experiences the chip freeze, so is there another work around required to eliminate the chip freezes?

Hi William,

Have you ever been able to communicate to the device or the device does not respond at all?

Regards,

Sachin S

Yes, what we see is the read of SYS_STATUS2 register reports the motor speed as zero. When I have a scope with current probe, I can see the I2C transaction that first gets zero in bits 15-0 of that register but the current pattern shows the motor is still running. Since we poll that register every 500ms we see that it will report zero irrespective of the operation of the motor and can only revive good data by resetting the chip. That of course shuts down the motor and we have to restart it to see the speed return.

Hi William,

Can you post the JSON file used? Can you check if any fault is in retry mode and all the faults are enabled?

Can you share the phase current waveform to understand if there is retry ? 

Thanks and Best Regards

Venkatadri S