推出XL-F28379D：LAUNCHXL-F28379D_EQEP_Problem

Odamate Firy

Part Number: LAUNCHXL-F28379D
Other Parts Discussed in Thread: TMS320F28335, TMS320F28379D, C2000WARE

Tool/software:

Issue Description: eQEP Frequency Calculation Anomaly on DSP TMS320F28379D

I am currently using the LAUNCHXL-F28379D development board, connected to a three-phase inverter controlling a motor. The system setup is as follows:

Current frequency: 10 Hz
ADC interrupt frequency: 10 kHz
Motor specification: 8 poles, expected speed of 150 RPM (verified with a tachometer)
Encoder resolution: 10000 CPR, using only A/B phase inputs without the Index signal
eQEP initialization: Based on the official example Eqep_pos_speed.c
When manually rotating the motor for one complete revolution, the oscilloscope shows a correct and complete waveform, confirming that the encoder signals are not faulty

Problem:

When outputting the QPOSCNT value as an analog signal via DAC, the expected frequency is 2.5 Hz (corresponding to 150 RPM), but the actual measured frequency is 6.8 Hz.
When increasing the current frequency to 20 Hz, the frequency corresponding to QPOSCNT becomes 7.8 Hz, still much higher than the theoretical value.
The same eQEP initialization configuration (including QUPRD, UPPS, CCPS, etc.) works correctly on the TMS320F28335 platform, with output frequency matching the theoretical value.

Attempted Solutions:

Adjusted the QUPRD (Unit Period Register) to various values.
Modified UPPS (Unit Position Prescaler) and CCPS (Capture Clock Prescaler) parameters.
Verified the motor’s actual speed to eliminate mechanical issues.
Tested the example code on TMS320F28335, confirming its correctness on that platform.

Request for Assistance:

Are there any known issues with the TMS320F28379D eQEP module that could cause such frequency anomalies?
In the case of using only A/B phase inputs, are there specific configurations required for QEPCTL (eQEP Control Register) or other parameters?
Are there additional debugging suggestions, such as analyzing interrupts, register states, or potential hardware-related issues?

Additional Information: I can provide signal waveform measurements or further describe the DAC output setup for analysis.

I hope to get insights from the community to resolve this issue. Thank you!

void POSSPEED_Init(void)
{
EALLOW;

EQep2Regs.QUPRD = 2000000;

EQep2Regs.QDECCTL.bit.QSRC = 00;
EQep2Regs.QDECCTL.bit.XCR = 0;
EQep2Regs.QEPCTL.bit.FREE_SOFT = 2;

EQep2Regs.QEPCTL.bit.PCRM = 01;

EQep2Regs.QEPCTL.bit.UTE = 1;
EQep2Regs.QEPCTL.bit.QCLM = 1;

EQep2Regs.QPOSMAX = 10000;
EQep2Regs.QEPCTL.bit.QPEN = 1;

EQep2Regs.QCAPCTL.bit.CEN = 1;
EQep2Regs.QCAPCTL.bit.CCPS = 6;
EQep2Regs.QCAPCTL.bit.UPPS = 2;

EQep2Regs.QPOSCNT = 0;

EDIS;
}

void InitEQep2Gpio(void)
{
EALLOW;

GpioCtrlRegs.GPAPUD.bit.GPIO24 = 1; // Disable pull-up on GPIO24 (EQEP2A)
GpioCtrlRegs.GPAPUD.bit.GPIO25 = 1; // Disable pull-up on GPIO25 (EQEP2B)
GpioCtrlRegs.GPAPUD.bit.GPIO26 = 1; // Disable pull-up on GPIO26 (EQEP2S)
GpioCtrlRegs.GPAPUD.bit.GPIO27 = 1; // Disable pull-up on GPIO27 (EQEP2I)

// Synchronize inputs to SYSCLK
// Synchronization can be enabled or disabled by the user.
// Comment out other unwanted lines.
//
GpioCtrlRegs.GPAQSEL2.bit.GPIO24 = 0; // Sync GPIO24 to SYSCLK (EQEP2A)
GpioCtrlRegs.GPAQSEL2.bit.GPIO25 = 0; // Sync GPIO25 to SYSCLK (EQEP2B)
GpioCtrlRegs.GPAQSEL2.bit.GPIO26 = 0; // Sync GPIO26 to SYSCLK (EQEP2S)
GpioCtrlRegs.GPAQSEL2.bit.GPIO27 = 0; // Sync GPIO27 to SYSCLK (EQEP2I)

GpioCtrlRegs.GPAMUX2.bit.GPIO24 = 2; // Configure GPIO24 as EQEP2A
GpioCtrlRegs.GPAMUX2.bit.GPIO25 = 2; // Configure GPIO25 as EQEP2B
GpioCtrlRegs.GPAMUX2.bit.GPIO26 = 2; // Configure GPIO26 as EQEP2S
GpioCtrlRegs.GPAMUX2.bit.GPIO27 = 2; // Configure GPIO27 as EQEP2I

EDIS;
}

11 months ago

0 Odamate Firy 10 months ago

Prodigy 10 points

While using the eQEP module of TMS320F28379D, the following error flags were detected in my status window:

QEPSTS.CDEF = 1: Capture direction error flag is set, indicating the encoder's direction signal is inconsistent with the capture direction.
QEPSTS.UPEVNT = 1: Unit position event flag is set, indicating a unit position event occurred.
QEPSTS.QDF = 1: Quadrature direction flag is set, showing the current quadrature direction.
QFLG.PHE = 1: Quadrature phase error flag is set, suggesting an abnormal phase relationship between the encoder's A and B signals.
QFLG.QDC = 1: Quadrature direction change interrupt flag is set, indicating an unexpected change in the direction signal.
QFLG.PCV = 1: Position counter underflow interrupt flag is set, indicating the position counter has underflowed.
QFLG.PCO = 1: Position counter overflow interrupt flag is set, indicating the position counter has overflowed.
QFLG.SEL = 1: Strobe event latch flag is set, showing that a strobe event occurred.

Question:
Do these flags indicate issues with my encoder signals or configuration? Specifically, the capture direction error (CDEF) and quadrature phase error (PHE) might be caused by signal interference or wiring issues. However, the simultaneous occurrence of unit position events (UPEVNT) and counter overflow/underflow (PCO/PCV) raises concerns about the eQEP configuration. What are the recommended steps for further debugging? Should I also check the hardware connections?

0 Ryan Ma 10 months ago in reply to Odamate Firy

TI__Mastermind 26916 points

Hi Odamate,

Are both TMS320F28379D clock configurations match that of TMS320F28335 for the eQEP? It's important that both eQEP clock sources have the same otherwise you will get incorrect readings.

TMS320F28335 can run at 100Mhz or 150Mhz depending on the device. TMS320F28379D can run up to 200Mhz. Both devices source the eQEP clock from the system clock.

Best,

Ryan Ma

0 Odamate Firy 10 months ago in reply to Ryan Ma

Prodigy 10 points

Thank you for your response. I have configured the QUPRD and CCPS parameters based on the example code provided in the TMS320F28379D documentation, ensuring they align with the clock speed differences between TMS320F28379D (200MHz) and TMS320F28335 (100MHz). However, I am uncertain if there are other parameters that might also need adjustment for the clock speed.

After updating my initialization settings, I observed that the QPOSCNT frequency is now closer to the theoretical value, but there is still some discrepancy. Additionally, the Phase Error (PHE) issue persists despite these changes.

Do you have any suggestions on other clock-related configurations or potential solutions to address the PHE problem?

It is observed that when rotating in a single direction, the position counter overflow flag (QFLG.PCO)

and the position counter underflow flag (QFLG.PCU) will be triggered.

This behavior is inconsistent with the expected behavior because in normal operation,

overflow and underflow of QPOSCNT should be mutually exclusive
Looking forward to your suggestions and solutions, thank you!

///////////////////////////////////////////////////////////

EQep2Regs.QPOSINIT = 1;
EQep2Regs.QUPRD = 2000000;

EQep2Regs.QDECCTL.bit.QAP = 0;
EQep2Regs.QDECCTL.bit.QBP = 0;

EQep2Regs.QDECCTL.bit.QSRC = 00;
EQep2Regs.QDECCTL.bit.XCR = 1;
EQep2Regs.QEPCTL.bit.FREE_SOFT = 2;

EQep2Regs.QEPCTL.bit.PCRM = 01;
EQep2Regs.QEPCTL.bit.UTE = 1;
EQep2Regs.QEPCTL.bit.QCLM = 1;
EQep2Regs.QCLR.all = 1;
EQep2Regs.QPOSMAX = 9999;
EQep2Regs.QEPCTL.bit.QPEN = 1;

EQep2Regs.QCAPCTL.bit.CEN = 1;

EQep2Regs.QCAPCTL.bit.CCPS = 6;
EQep2Regs.QCAPCTL.bit.UPPS = 4;

EQep2Regs.QCAPCTL.bit.CEN = 0;
EQep2Regs.QPOSCNT = 0;
EQep2Regs.QEINT.all = 0;

///////////////////////////////////////////////////////////

0 Ryan Ma 10 months ago in reply to Odamate Firy

TI__Mastermind 26916 points

Hi Odamate,

Odamate Firy said:
Additionally, the Phase Error (PHE) issue persists despite these changes

Can you scope what your input signals are? Are they phase shifted by 90 degrees? Is this the only error now that persists?

Best,

Ryan Ma

0 Odamate Firy 10 months ago in reply to Ryan Ma

Prodigy 10 points

I have attached the AB input signals, including those captured during manual rotation of the motor and while the motor is running (which includes some additional noise). Additionally, I’ve provided the monitoring window for the QFLG register.

I have also modified QUPRD=100, and observed that the PHE flag repeatedly appears and disappears. When manually rotating the motor, the QPOSCNT frequency seems correct. However, at 150 RPM, the QPOSCNT frequency becomes inaccurate and fluctuates.

Could you kindly help identify the possible causes of these issues? Your advice would be greatly appreciated.

Best regards,

manual rotation of the motor

motor is running (which includes some additional noise ，already filtered。)

motor is running (which includes some additional noise ，without filtered。)

monitoring window for the QFLG register.

0 Ryan Ma 10 months ago in reply to Odamate Firy

TI__Mastermind 26916 points

Hi Odamate,

How are you calculating the QUPRD? Have you had a chance to take a look at the calculators within the c2000ware sdk under the eQEP exmamples folder for both ex1 and ex2?

Best,

Ryan Ma

0 Odamate Firy 10 months ago in reply to Ryan Ma

Prodigy 10 points

Hi Ryan,

Thank you for your suggestion earlier. I revisited my configuration and resolved the issue by adjusting the synchronization clock settings in the GPIO initialization function for eQEP2.

Here’s the updated code snippet:

void InitEQep2Gpio(void)
{
EALLOW;

//
// Disable internal pull-up for the selected output pins
// for reduced power consumption
// Pull-ups can be enabled or disabled by the user.
// Comment out other unwanted lines.
//
GpioCtrlRegs.GPAPUD.bit.GPIO24 = 1; // Disable pull-up on GPIO24 (EQEP2A)
GpioCtrlRegs.GPAPUD.bit.GPIO25 = 1; // Disable pull-up on GPIO25 (EQEP2B)
GpioCtrlRegs.GPAPUD.bit.GPIO26 = 1; // Disable pull-up on GPIO26 (EQEP2S)
GpioCtrlRegs.GPAPUD.bit.GPIO27 = 1; // Disable pull-up on GPIO27 (EQEP2I)

//
// Synchronize inputs to SYSCLK
// Synchronization can be enabled or disabled by the user.
// Comment out other unwanted lines.
//
GpioCtrlRegs.GPAQSEL2.bit.GPIO24 = 1; // Sync GPIO24 to SYSCLK (EQEP2A)
GpioCtrlRegs.GPAQSEL2.bit.GPIO25 = 1; // Sync GPIO25 to SYSCLK (EQEP2B)
GpioCtrlRegs.GPAQSEL2.bit.GPIO26 = 1; // Sync GPIO26 to SYSCLK (EQEP2S)
GpioCtrlRegs.GPAQSEL2.bit.GPIO27 = 1; // Sync GPIO27 to SYSCLK (EQEP2I)

//
GpioCtrlRegs.GPAMUX2.bit.GPIO24 = 2; // Configure GPIO24 as EQEP2A
GpioCtrlRegs.GPAMUX2.bit.GPIO25 = 2; // Configure GPIO25 as EQEP2B
GpioCtrlRegs.GPAMUX2.bit.GPIO26 = 2; // Configure GPIO26 as EQEP2S
GpioCtrlRegs.GPAMUX2.bit.GPIO27 = 2; // Configure GPIO27 as EQEP2I

EDIS;
}

The key was ensuring the input pins were properly synchronized to SYSCLK (GPAQSEL2.bit).

This change stabilized the signals and resolved the issue.

Thanks again for pointing me in the right direction!

Best,

Odamate Firy

C2000™︎ microcontrollers

C2000 microcontrollers forum

推出XL-F28379D：LAUNCHXL-F28379D_EQEP_Problem

Issue Description: eQEP Frequency Calculation Anomaly on DSP TMS320F28379D

Problem:

Attempted Solutions:

Request for Assistance: