MCT8329A: Problem with multiple ALIGN in start-up

Conor

Guru 11990 points

Part Number: MCT8329A

Hi,

I have questions about retries in AlignMode.

Q1.
During an AlignMode operation, the ALIGN operation stops when the ALIGN_TIME has not been reached, and then ALIGN is performed again.
What are the causes of this retry?

Q2.
In some cases, the ALIGN retry continues several times, and the time from the start until the specified RPM is reached varies greatly.
The time to reach the specified rpm is usually 0.4s, but it can be as long as 2s, which may be a problem in terms of product specifications.
Please let us know if there is a setting to eliminate the retry factor.

We have prepared the attached documents to help you better understand Q1 and Q2.
Problem with multiple ALIGN in start-up.pdf

Thanks,

Conor

over 2 years ago

0 Joshua Horlander Cruz over 2 years ago

TI__Mastermind 23750 points

Hi Conor,

After looking at the provided PDF I suspect that the ALIGN_CURR_THR maybe getting exceeded leading to the retry to occur.

Is the nFault pin going low? If it is not can you set CBC_ILIMIT_MODE to 0h and see if the nFault pin goes low during these retry times?

Regards,

Joshua

0 Conor over 2 years ago in reply to Joshua Horlander Cruz

Guru 11990 points

Hi Joshua,

Faul is not output even if Align Retry occurs. (CBC_ILIMT_MODE=1h, MTR_LCK_MODE=1h LOCK_ILIMIT_MODE=1h, all 1h)

Also the currents in A, B, and C phases were observed, but no overcurrents were found. I will send you the A phase waveform for reference.

2072.Schematic2.pdf

Thanks,

Conor

0 Joshua Horlander Cruz over 2 years ago in reply to Conor

TI__Mastermind 23750 points

Hi Conor,

I understand that you have not observed any overcurrent events, but to be 100% sure that an OC event is not the issue could you please see if a Fault gets reported when CBC_ILIMT_MODE =0h?

Also, have you preformed an ABA swap, did this issue follow the device?

Regards,

Joshua

0 Conor over 2 years ago in reply to Joshua Horlander Cruz

Guru 11990 points

Hi Joshua,

We have confirmed the operation by updating CBC_ILIMT_MODE from 1 to 0 in the FAULT_CONFIG2 register.

Then, the n_Fault pin output became as shown in the PDF below, although the Align retry operation does not occur.

0005.Schematic2.pdf

The n_Fault pin output repeats High/Low during ALIGN and OPEN LOOP operations, and is High and stable during CLOSED LOOP. The motor operation has been repeated and no Align Retry operation has occurred.

Thanks,

Conor

0 Joshua Horlander Cruz over 2 years ago in reply to Conor

TI__Mastermind 23750 points

Hi Connor,

If you increase the current limit values, CBC_ILIMIT and OL_ILIMIT, do you see improvement with the number of faults/operation of the device?

Can you provide a capture of SOx, SP, SN, and nFault?

What value is your RSENSE resistor?

Regards,

Joshua

0 Conor over 2 years ago in reply to Joshua Horlander Cruz

Guru 11990 points

Hi Joshua,

Joshua Horlander Cruz said:
If you increase the current limit values, CBC_ILIMIT and OL_ILIMIT, do you see improvement with the number of faults/operation of the device?

When the Align current was changed to 7.5 A and the OpenLoop current to 10 A, there were cases of normal start-up and start-stop.

Even in the case of normal start-up, the Fault signal flutters in the initial stages of Align, OpenLoop and ClosedLoop, after which the Fault signal remains High.
In the case of a start-up stop, the Fault signal remains Low and the FAULT STATUS on the GUI lights up red.

Joshua Horlander Cruz said:
Can you provide a capture of SOx, SP, SN, and nFault?

A waveform is attached.

Capture.pdf

Joshua Horlander Cruz said:
What value is your RSENSE resistor?

RSENSE is 2 mΩ.

Thanks,

Conor

0 Joshua Horlander Cruz over 2 years ago in reply to Conor

TI__Mastermind 23750 points

Hi Conor,

I will need some time to look over the information, I will aim to get back to you by Friday.

Regards,

Joshua

0 Joshua Horlander Cruz over 2 years ago in reply to Joshua Horlander Cruz

TI__Mastermind 23750 points

Hi Conor,

Could you provide me the fault that is being reported in the FAULT_STATUS registers when the nFault pin goes low?

Regards,

Joshua

0 Conor over 2 years ago in reply to Joshua Horlander Cruz

Guru 11990 points

Hi Joshua,

FAULT STATUS is as follows.

Motor Lock and Loss of Sync are outputting FAULT.

Thanks,

Conor

0 Joshua Horlander Cruz over 2 years ago in reply to Conor

TI__Mastermind 23750 points

Hi Conor,

To fix the loss of sync fault please see section 7 of our FAQ on Common MCx faults, also please see this E2E post which covers the loss of sync fault.

Regards,

Joshua

0 Conor over 2 years ago in reply to Joshua Horlander Cruz

Guru 11990 points

Hi Joshua,

Q1.
What are the factors that cause repeated Aligns? (e.g. UVLO detection in the VM).

Q2.
The Reserved value can be set to 1. Is there a problem with setting the Reserved value to 1?

Thanksl,

Conor

0 Joshua Horlander Cruz over 2 years ago in reply to Conor

TI__Mastermind 23750 points

Hi Conor,

Conor said:
What are the factors that cause repeated Aligns? (e.g. UVLO detection in the VM).

Repeated Aligns could be caused by a Motor Lock Fault, a Cycle-by-Cycle Current Limit Fault, a Lock-Detection Current Limit Fault. All of these faults have the ability to automatically retry, latch, or not have an action based on the setting chosen (see Table 7-2 in section 7.3.20 for more information). If these faults were occurring, the faults setting was to automatically retry, and the motor were to be stationary after the retry time then the the MCT8329 would attempt to align after every retry leading to repeated aligns.

Conor said:
The Reserved value can be set to 1. Is there a problem with setting the Reserved value to 1?

We do not recommend changing the value of any of the reserved bits from its default value.

Regards,

Joshua

0 Conor over 1 year ago in reply to Joshua Horlander Cruz

Guru 11990 points

Hi Joshua,

Thank you for your answer.

What can happen if the reserve bit is changed? As background to my question, we are experiencing a situation where the MCT8329A on our custom board cannot access the EEPROM or RAM, and we are concerned that changing the reserved bits in the GUI may have caused this situation.

Thanks,

Conor

0 Anthony Lodi over 1 year ago in reply to Conor

TI__Mastermind 26416 points

Hi Connor,

Today is a holiday in the US, but we will aim to get back to you by the end of the week.

Regards,

Anthony Lodi

0 Joshua Horlander Cruz over 1 year ago in reply to Conor

TI__Mastermind 23750 points

Hi Conor,

This reserve bit does not affect communication between the MCU and the MCT8329A.

What are the voltages at the AVDD, DVDD, and VREG pins when you are attempting to communicate with the MCT8329A?

Have you used the find address button to see if the I2C address of the MCT8329A may have been changed?

Regards,

Joshua

0 Conor over 1 year ago in reply to Joshua Horlander Cruz

Guru 11990 points

Hi Joshua,

Joshua Horlander Cruz said:
What are the voltages at the AVDD, DVDD, and VREG pins when you are attempting to communicate with the MCT8329A?

Have you used the find address button to see if the I2C address of the MCT8329A may have been changed?

Power supply to the MCT8329A is fine; the I2C address has not been changed.

The situation is currently only accessible on certain custom board, as it was verified on other custom boards and was written successfully.

Thanks,

Conor

0 Joshua Horlander Cruz over 1 year ago in reply to Conor

TI__Mastermind 23750 points

Hi Conor,

So the MCT8329 that was experiencing a I2C communication issue is able to communicate without issue when it was placed onto a different custom board?

If you were able to communicate with the MCT8329 before on the problem custom board what was done between the time when a good communication was seen and the device stopped responding to I2C commands?

Regards,

Joshua

Motor drivers

Motor drivers forum

MCT8329A: Problem with multiple ALIGN in start-up