TMS320F280039C: Dual-Axis Motor Drive Using Fast Current Loop (FCL) and SFRA on a Single MCU Reference Design example: Erratic values of speed

Please follow the example user's guide to migrate the lab to the LAUNCH-XL-F280039C. You should need to modify the device configuration codes like ADC, PWM, QEP according to the boards you used.

Hi Yanming,

The PWM's, ADCs were configured as per LAUNCH-XL-F280039C, PWM signals were checked in FCL_BUILD_LEVEL_1 and values of ADC were verified with  FCL_params.Vdc values, QEP was also configured but the QPOSCNT register value showing 0. The QEP configuration is

Now, the motorVars[0].speed.Speed  is not giving correct values and also the encoder was checked separately and was working fine. 

Regards,

Raghu

Did you try to run the lab from Build Level 1 and see which build level will have issue?

You may take a look at the LAUNCH-XL-F280039C user's guide to set the switch to enable the related GPIO connect to the interface header for QEP.

Yes, we were following the Dual-Axis Motor Drive Using Fast Current Loop (FCL) and SFRA on a Single MCU Reference Design guide and were doing from FCL_BUILD_LEVEL1. 

The QEP select switch on the LAUNCH-XL-F280039C was set to J12 which is EQEP1 header. Also, we've ran an encoder example code eqep_ex2_pos_speed and the results were satisfactory. 

In the reference design which was built for LAUNCH-XL-F280049C, the QEP configuration was made to work with index pin of encoder, here we have reconfigured to work without index pin. the values of motorVars[0].speed.Speed was either 0 or 1. 

Regards,

Raghu

As per our understanding, when motorVars[0].ctrlState  is set to CTRL_RUN,  motorVars[0].ptrFCL->lsw  should change from ENC_ALIGNMENT to ENC_WAIT_FOR_INDEX and the motor should start rotating, finding for index pin which is actually happening. also, at the same time the motor is responding to motorVars[0].speed.Speed values. at this point in time shouldn't it calculate the speed?

Small correction, in my previous message I told that "the values of motorVars[0].speed.Speed was either 0 or 1", it is actually the values of QPOSCNT register.

You need to run the code in Build level 2, otherwise, the lab doesn't work to spin the motor without Index.

We've bought in one encoder with index pin and the issue is still happening.

As mentioned above, try to run the lab in build level 2 to verify the encoder and the configuration for eQEP as well. You can run the original lab with the supporting boards for the encoder first, and then test on the board you have. To know the issue is from the encoder or from the configuration code.

Running the lab in build level 2, check the output signals of the encoder, and check the eQEP registers.

Hi Yanming,

As you suggested, We have ran the original lab with LAUNCH-XL-F280049C and BOOSTXL-3PHGANINV. motorVars[0].speed.Speed  and QPOSCNT values were fine.

Now we ran on LAUNCH-XL-F280039C but motorVars[0].speed.Speed  value was erratic and QPOSCNT value was either 0 or 1.  Here motorVars[0].ptrFCL->lsw was ENC_WAIT_FOR_INDEX ,  it is not able to detect the index pin. but we used encoder with Index pin.

Hi Raghu,

Perhaps ensure the GPIO inputs are actually connected to the eQEP index pulse pin exiting from level translator. Use DMM ring out the entire path up to the MCU on top the pin, not on top wetting flat. A poor pin connection can sometimes contact even under light test probe pressure. 

Regards,

raghu dharmana said:

Now we ran on LAUNCH-XL-F280039C but motorVars[0].speed.Speed  value was erratic and QPOSCNT value was either 0 or 1.  Here motorVars[0].ptrFCL->lsw was ENC_WAIT_FOR_INDEX ,  it is not able to detect the index pin. but we used encoder with Index pin.

As mentioned above, you have to check if the EQEP is configured correctly, and the switch on LAUNCH-XL-F280039C is set to the right position.

You need to configure the related GPIO as eQEP inputs, and configure the EQEP registers as F28004x.

Hi Genatco,

Thanks for replying.

The QEP select switch was set to J12 &J13 on LAUNCH-XL-F280039C. An encoder project was ran on this board which is working fine but the same configuration when ran in Dual-Axis Motor Drive Using Fast Current Loop (FCL) and SFRA was not working. I don't think there are any poor or loose connections. GPIO inputs were double checked and Pin configurations were checked.

raghu dharmana said:

GPIO inputs were double checked and Pin configurations were checked.

Hi Raghu,

My mistake, It seemed you were testing encoder (FCL index SFRA) on the x49c but same encoder failed on x39c. Perhaps the x39c library calls are different in some way or the project compile omits necessary code for SFRA interrupt or handler in the x49c project hal.h/c. 

Do you change the codes below in HAL_setupCLA() in dual_axis_servo_drive_hal.c file according to the using PWM on LAUNCH-XL-F280039C?

// Enable EPWM6 INT trigger for CLA TASK1
CLA_setTriggerSource(CLA_TASK_1, CLA_TRIGGER_EPWM1INT);

// Enable EPWM1 INT trigger for CLA TASK5
CLA_setTriggerSource(CLA_TASK_5, CLA_TRIGGER_EPWM7INT);

Hi Genatco,

We have configured the eQEP module as per x39C and We have excluded SFRA for now. Currently as Yanming suggested we were in FCL
_BUILD_LEVEL2 to verify eEQEP.

Hi Yanming,

// Enable EPWM6 INT trigger for CLA TASK1
CLA_setTriggerSource(CLA_TASK_1, CLA_TRIGGER_EPWM1INT); 

 This is already done and accordingly this part of code was changed in dual_axis_servo_drive_user.h 

We were focusing on only one motor and trimmed down all the code pertaining to motor 2. so 

// Enable EPWM1 INT trigger for CLA TASK5
CLA_setTriggerSource(CLA_TASK_5, CLA_TRIGGER_EPWM7INT);

So,this is not available here.

You may try to configure all of peripherals for dual motor, even you only use one motor. Where will the PC stop at when you debug the code within CCS? And any values in those eQEP registers?

Hi Yanming,

Today we did a series of activities on this Dual-Axis Motor Drive Using Fast Current Loop (FCL) and SFRA on a Single MCU Reference Design lab.

NOTE: The entire things were done in FCL_BUILD_LEVEL2.

1.  As you suggested, we have created a new project "49C_with_39C_source_files_2_motors" in which we changed the PROJECTSPEC file,  dual_axis_servo_drive_user.h and related files to work with LAUNCH-XL-F280039C and linker cmd file was edited to execute from FLASH(XIP).In this encoder was assigned with eQEP1 & and the other time with eQEP2 , both the times QPOSCNT register was either 0 or 1 and values of motorVars[0].speed.Speed were erratic.
2. Now, We went back to the original configuration per Dual-Axis Motor Drive Using Fast Current Loop (FCL) and SFRA on a Single MCU Reference Design document, LAUNCH-XL-F280049C, it was not working when eQEP1 was assigned .  motorVars[0].speed.Speed  was 0 and QPOSCNT register was also 0. When eQEP2 was assigned, it was working fine.  motorVars[0].speed.Speed & QPOSCNT values were fine.
3. Anyways, our original project which we were working in which we trimmed down the code of motor_2  and running using x39C source files also following the same manner as mentioned in the point 1.

The reason for Trimming the  motor_2 code is the RAM size of x39C is smaller(69kb) than X49c(100kb) and however we want to run only one motor.

Now,  what is the way forward?

raghu dharmana said:

The reason for Trimming the  motor_2 code is the RAM size of x39C is smaller(69kb)

Why not run the entire project from flash banks just to see what happens. Using #pragma sections to move functions/code into SRAM sometimes parts of modules fail to communicate across memory addresses. Perhaps move sections together, using memory browser to locate the #pragma sections.

Hi Genatco,

We were running the project from FLASH itself(XIP). I don't think it is failing because when we tried to debug line by line the HAL_setupQEP(handle); is executing and eQEP is configuring. Also, position counter is also enabled(QPEN bit is 1 in QEPCTL register). So, as per our understanding the QPOSCNT should be incrementing. 

raghu dharmana said:

So, as per our understanding the QPOSCNT should be incrementing.

Good reason for using #pragma to relocate some functions into SRAM sections and setting general optimization level in project properties. Sometime setting Global optimizations on entire project can execute SRAM section functions too fast. Such causing timing issues for CPU capturing data from peripheral registers on the MCU local bus during PIE interrupt (EQEPxINT). Adding control #pragma to suspect functions setting optimization level lower for the compiler when it encounters #pragma statement may help. Otherwise could there be an interrupt conflict of some kind? Perhaps check the EQEPxINT flag is asserting, being cleared in PIE register view.

.     

Can you check if all of the eQEP configuration registers of F28003x have the same value as F28004x? Is the clock for eQEP enabled? The code size should be far smaller than the RAM size of both devices.

Hello,

The clock is enabled. The registers values for both F28003x and F28004x were same. Code should be smaller, that is why we trimmed the motor2, anyways we were running the code from flash (389kb in F28003x ).

It doesn't matter that the code is running out of Flash or RAM. I don't think you need to make some bigger changes, just need to change the device configuration as discussed above according to the using peripherals, ADC, eQEP, PWM and a few GPIOs. 

1. S5 on LAUNCH-XL-F280039C is et correctly.

2. GPIOs for eQEP are configured.

3. eQEP

4. ADC and PWM

5. CLA trigger event 

Hello Yanming and Genatco,

The problem was as this project is essentially built for x49C, HAL_setupGPIO(handle); contains pins pertaining to x49C. while we changed the pins to work with x39C. the actual eQEP GPIO pins for x49C were not changed and that created the problem.

We would like to keep this thread open as we are proceeding to further levels.

Regards,

Raghu