MCT8316A: I2C communication is dead

Hi Goran,

After reviewing your schematic, I only have one suggestion for your schematic for the Vm Cap C70, which is recommended to be 10uF.

Are you using a custom MCU to send I2C commands to the MCT8316A? What target address are you using?

Do you have an MCT8316AEVM? if so, could you try jumper wiring the SCL, SDA, and AGND pins from the EVM's J6 headers.

1. Disconnect jumpers for SCL, SDA, and AGND from J6
2. Jumper wire from the left side of these 3 pins over to your custom PCB
3. Connect EVM to PC through micro usb
4. Power up custom PCB
5. Try read/writing using the MCT8316A_GUI

Regards,
Eric C.

Hi Eric,

yes, I am using a STM32H750. Target address is 0x00. No, I do not have an EVM but I'll check with the office to see if one is available.

Regards,

Goran

Hi Goran,

If possible, could you please capture the I2C SCL and SDA lines with a logic analyzer and provide the waveform?

It could be timing related issue depending on how the protocol is implemented on your STM32H750. Please refer to the attached CCS project for a software implementation of the I2C communication protocol using an MSP430FR2311:

Tested on the MSP-EXP430FR2311 LaunchPad:
5086.SoftwareI2C_MSP430FR2311_MCF8316AEVM.zip

Alternatively, below a CCS project for a hardware implementation of the I2C communication using an MSP430FR2355:

Tested on the MSP-EXP430FR2355 LaunchPad:
1512.HardwareI2C_MSP430FR2355_MCF8316AEVM.zip

Please note that the example projects provided above were made for the MCF8316A, so you'll need to update the register addresses and I2C target address accordingly for MCT8316A.

Well, the capture is very simple: A start condition is generated, the master generates 9 clocks with SDA low (target ID 0) and then both the SCL and SDA remain low "forever".

I recall that a new revision for this device was scheduled to be released Q4-22. Is it available yet?

Hi Goran,

It's difficult to tell what the issues in your I2C commands are without seeing the logic waveform capture. What I2C clock speed are you using? Is the I2C implemented with software bit-banging or hardware I2C peripheral?

If you don't have a MCT8316AEVM, I would recommend getting a MSP-EXP430FR2355 LaunchPad and using the above Hardware I2C project to give you a reference logic waveform for what working I2C communications should look like.

I don't have the exact release date for the new revision of the MCT8316A as of now.

Regards,
Eric C.

We are using the built-in I2C port on an STM32H750.

So, I found the issue, two DAC chips on the same bus is responding/interfering with the traffic to the General Call ID 0. Why did you choose that ID... now we will have to add a MUX to the bus...

Regarding the "100us delay between bytes issue", I tried to use a SCL frequency of 10kHz but got timing issues. It may be that the ST tool fails to generate a valid 10kHz I2C port config, right now I don't know.

Regarding the "100us delay beween bytes" requirement, can you be specific about when that is required. So far, I've successfully sent to 20 registers using 32bits at full 100kHz speed (no delay). I seem to recall the NACK issue is only when the chip is "working", i.e. the  motor is started, is that correct? Would an alternative be to just re-send the complete register read/write command at NACk until it works or will that disturb the chip?

Hi Goran,

Sorry that you ran into issue with the 0x00 target address. This is also an errata in the MCT8316A listed here. This will be fixed in the next device version to allow the I2C target address to be user configurable.

The 100us delay is needed in between each individual byte in an I2C transaction. This is to address a different issue than the I2C communication problem of the MCF8316A where the device algorithm can potentially lock up from I2C commands while motor is spinning. MCT8316A has no problems with continued I2C transactions while motor is spinning.

Regards,
Eric C.

Thanks for your update! I need to double-check, the MCT8316AV does not need a 100us delay between bytes? This contradicts the data sheet (SLLSFH8B Aug. 2021 - Rev Feb 2022), section 8.6.2 on page 85.

Hi Goran,

Today is a TI holiday, but we will aim to provide a response by the end of the week.

Regards,

Anthony