TMS320F28069M: eCAP1 setup with RTOS

Your Hwi set up seems fine. I don't know when you're calling InitECapture() in the application (before or after BIOS_start()), but take care modifying the IER and registers yourself without using the Hwi module functions in case you're accidentally disabling the timer interrupt for the system tick. The Hwi module looks like it's configured to enable it for you anyway.

Similarly, make sure you aren't calling InitPieVectTable() or using the __interrupt keyword on your Hwi function. SYS/BIOS should handle those things for you.

Can you the ECAP event flag getting set in the registers window?

Whitney

I call InitECapture() before BIOS_start(). I am not calling those other functions you mentioned. However, I am using pin J6-pin55 but I notice that eCAP1 is assigned to multiple pins. Which pin am I supposed to connect to? Where in the code do I specify which GPIO to use? I have attached a screen shot of the eCAP1 register as I am running my current code.

You've modified InitECap1Gpio() to uncomment the GPIO24 lines, correct? If you edit the ecap_capture_pwm example to use GPIO24, does it work? It sounds like you are using the correct pin on the LaunchPad.

Whitney

I didn't realize that InitECap1Gpio() defined the GPIO that eCAP1 would use. As a result, I changed my hardware to read GPIO5.

void InitECap1Gpio(void)

{

EALLOW;

/* Enable internal pull-up for the selected pins */

// Pull-ups can be enabled or disabled by the user.

// This will enable the pullups for the specified pins.

// Comment out other unwanted lines.

GpioCtrlRegs.GPAPUD.bit.GPIO5 = 0; // Enable pull-up on GPIO5 (CAP1)

// GpioCtrlRegs.GPAPUD.bit.GPIO11 = 0; // Enable pull-up on GPIO11 (CAP1)

// GpioCtrlRegs.GPAPUD.bit.GPIO19 = 0; // Enable pull-up on GPIO19 (CAP1)

// GpioCtrlRegs.GPAPUD.bit.GPIO24 = 0; // Enable pull-up on GPIO24 (CAP1)

// Inputs are synchronized to SYSCLKOUT by default.

// Comment out other unwanted lines.

GpioCtrlRegs.GPAQSEL1.bit.GPIO5 = 0; // Synch to SYSCLKOUT GPIO5 (CAP1)

// GpioCtrlRegs.GPAQSEL1.bit.GPIO11 = 0; // Synch to SYSCLKOUT GPIO11 (CAP1)

// GpioCtrlRegs.GPAQSEL2.bit.GPIO19 = 0; // Synch to SYSCLKOUT GPIO19 (CAP1)

// GpioCtrlRegs.GPAQSEL2.bit.GPIO24 = 0; // Synch to SYSCLKOUT GPIO24 (CAP1)

/* Configure eCAP-1 pins using GPIO regs*/

// This specifies which of the possible GPIO pins will be eCAP1 functional pins.

// Comment out other unwanted lines.

GpioCtrlRegs.GPAMUX1.bit.GPIO5 = 3; // Configure GPIO5 as CAP1

// GpioCtrlRegs.GPAMUX1.bit.GPIO11 = 3; // Configure GPIO11 as CAP1

// GpioCtrlRegs.GPAMUX2.bit.GPIO19 = 3; // Configure GPIO19 as CAP1

// GpioCtrlRegs.GPAMUX2.bit.GPIO24 = 1; // Configure GPIO24 as CAP1

EDIS;

}

Now, this is what the eCAP1 register looks like after making that hardware change. However, I am still not getting anything from CAP1, CAP2, CAp3, or CAP4.

This is the function I am using for the HWI when eCAP1 is triggered.

//-----------------------------------------

// ======== SensorMeasurementHWI ========

//-----------------------------------------

Void SensorMeasurementHWI()

{

unsigned int Measurement[2] = {0,0};

SensorHighPeriod = (unsigned int)ECap1Regs.CAP2 - (unsigned int)ECap1Regs.CAP1; // Calculate the PWM duty period (rising edge to falling edge)

SensorPeriod = (unsigned int)ECap1Regs.CAP3 - (unsigned int)ECap1Regs.CAP1; // Calculate the PWM period (rising edge to rising edge)

Measurement[HIGHPERIOD] = SensorHighPeriod;

Measurement[PERIOD] = SensorPeriod;

Mailbox_post(SensorMeasurement, &Measurement, BIOS_NO_WAIT);

ECap1Regs.ECCLR.bit.CEVT4 = 1;

ECap1Regs.ECCLR.bit.INT = 1;

ECap1Regs.ECCTL2.bit.REARM = 1;

PieCtrlRegs.PIEACK.all = PIEACK_GROUP4; // Acknowledge this interrupt to receive more interrupts from group 4

}

It looks like your eCAP configuration is pretty much the same as the ecap_capture_pwm example. Does the example work as expected when you run it as-is? Is it integrating it into a SYSBIOS project that seems to break it?

It seems like it's an issue with the eCAP or the pin configuration since you aren't seeing the flags get set in the eCAP registers, but just to confirm that the Hwi setup is okay, can you use the ECFRC register to test that the ISR executes?

Whitney

This is the code I have been using to generate the test signal for the eCAP and this is where I added the ECFRC lines of code.

Void TestTask()

{

unsigned int Measurement[2] = {0,0};

while(1)

{

ECap1Regs.ECFRC.bit.CEVT1 = 1;

ECap1Regs.ECFRC.bit.CEVT2 = 1;

ECap1Regs.ECFRC.bit.CEVT3 = 1;

ECap1Regs.ECFRC.bit.CEVT4 = 1;

GpioDataRegs.GPATOGGLE.bit.GPIO6 = 1; // Drive Tilt Motor output J8-pin80

GpioDataRegs.GPATOGGLE.bit.GPIO7 = 1; // Drive Roll Motor output J8-pin79

Task_sleep(Period);

if(TiltMotorDirection == FWD)

GpioDataRegs.GPASET.bit.GPIO8 = 1; // Set Tilt Motor direction J8-pin78

else if(TiltMotorDirection == REV)

GpioDataRegs.GPACLEAR.bit.GPIO8 = 1; // Clear Tilt Motor direction J8-pin78

else

{

System_printf("Stop Driving the Tilt Motor\n");

System_flush(); // force SysMin output to console

}

if(RollMotorDirection == FWD)

GpioDataRegs.GPASET.bit.GPIO9 = 1; // Set Roll Motor direction J8-pin77

else if(RollMotorDirection == REV)

GpioDataRegs.GPACLEAR.bit.GPIO9 = 1; // Clear Roll Motor direction J8-pin77

else

{

System_printf("Stop Driving the Roll Motor\n");

System_flush(); // force SysMin output to console

}

}

}

This is the screen shot of the eCAP1 after the new lines of code was added

Did your Hwi function execute when you used ECFRC? I see the ECFLG bits were set.

Have you used an oscilloscope or similar tool to confirm that your test signal is as expected?

Whitney

The HWI did not seem to execute when I used ECFRC. I have used an oscilloscope to verify that the test signal is working. Can I send you my project file? If so, how can I because I don't see how I can attach it to this forum?

I don't have the hardware to run it with me at the moment, but I can at least look at the code. Go to Insert -> Image/video/file and see if that lets you upload a project.

Did you ever confirm that the plain non-BIOS ecap_capture_pwm  example works on your board?

Whitney

4478.Testbench.zip

I attached my code above.

I tried to run the example code but it won't compile because I don't have the right compiler installed.

Will CCS let you change the compiler version to one you do have installed or is it not even letting you import the project? Or could you make a new project and copy the example file into it? There's a lot going on in your actual project, so it would be nice to see if we can isolate the issue a bit.

By default SYS/BIOS will try to use the Boot module to configure the system clock which by conflict with the clock configuration in InitSysCtrl(). It seems like it's probably working out okay in your case if your test signal is toggling at the expected frequency, but it's generally a good idea to disable one or the other.

Similarly, you need to make sure that any CPU Timers you're using aren't already being used by SYS/BIOS for doing the system tick or timestamps. I don't recall which one it uses by default, but you can configure it to use a specific one so you can be sure they don't overlap.

That being said, I don't think either of those things would actually result in the eCAP failing to detect edge events.

Whitney

To be honest, it was a process trying to get the project file I sent you working with the compliers so I don't want to waste time trying to figure out the compilers for the example. However, a lot of the functions in my project aren't used so I can simplify the project to only what I use and reattach it.

1588.Testbench.zip

I simplified the file but I left in the CAN and PWM stuff but it is not being used at this time. The main functions to look at are the

InitECapture()  // this is the function that initializes the eCAP

SensorMeasurementHWI()    //this is the HWI that is called when the eCAP is triggered

TestTask()   //generates the PWM signal

Whitney,

I made those corrections and not I see eCAP is updating CAP1. However, CAP2, CAP3, and CAP4 aren't updating? Is there something in the code I need to add to read those?

I have been playing with the signal so it seems that 1Hz was too slow so I increased it and I saw CAPs 1-4 were reporting but if I increased the signal too much then the CAPs wouldn't work. Is there an overflow counter that I need to factor in? I don't feel like i have that many tasks running to hold up the system but how do I increase the system clock? How do I increase the clock of the eCAP1?

I also noticed that when I run the programmer in the debugger, the PWM signal is the slower frequency and duty cycle that jumps around. But when I stop the debugger the program is still running and the PWM signal is much faster but with a stable duty cycle. Do you know why this is?

Is your SYSCLK running at 90 MHz? Like I said in an earlier post, SYS/BIOS will try to configure the SYSCLK itself which may lead to some conflicts if you then call InitSysCtrl(). My recommendation is to enable the Boot module and uncheck the "Configure the PLL" box. Then go into the BIOS settings and tell it your CPU clock frequency is 90 MHz. In the cfg script you should see

BIOS.cpuFreq.lo = 90000000;
Boot.configurePll = false;

It's sometimes helpful to pull up ROV and look at the Clock module, make a note of the number of ticks, run for 10 seconds, halt and check the ticks again, and make sure roughly 10,000 have passed.

It looks like your eCAP1 prescaler is set to /1 already, so you can't make it any faster.

Whitney

I was able to set the system clock as you instructed and verified that the cfg script was updated. However, I still observe the same behavior when switching between the debugger and standalone modes.

I provided the latest eCAP1 register screenshot and I notice that CAP1-4 all update to the same value. I am using a stable signal for a known output that I am monitor now that operates at 250Hz. I also removed the following lines of code from TestTask() function

ECap1Regs.ECFRC.bit.CEVT1 = 1;

ECap1Regs.ECFRC.bit.CEVT2 = 1;

ECap1Regs.ECFRC.bit.CEVT3 = 1;

ECap1Regs.ECFRC.bit.CEVT4 = 1;

Good to see those capture events working now. Is your Hwi function executing as expected now?

So when you have the debugger connected the PWM waveform is incorrect? Or is it specifically that booting standalone corrects the issue even if the debugger is connected afterward (like in this video--connect but make sure it doesn't reset the device)?

Whitney

No, I just simply hit the Debug button in CCS and it switches over to the CCS Debug window. It loads and flashed the code and I hit run within the CCS Debug window. While in the Debug window, the signal reads a slower unstable frequency with a unstable duty cycle. However, when I simply press the terminate button in the CCS Debug window, CCS switches over to the CCS Edit window and the signal now becomes stable with a faster frequency and stable duty cycle.

How is the TBCTL.FREESOFT field configured? If you set it to "free run" does it help?

Whitney

Where do I find TBCTL.FREESOFT? It is not in the CFG script.

I am now having issues with my XINT. They used to work but now they are no longer getting called. I noticed that the BIOS has 2 different areas to define the HWI functions and I am not able to use HWI (ti.sysbios.family.c28) without getting errors.

I see that I get the following error when I do a clean build

Product com.ti.rtsc.TIRTOSc2000 v2.10.1.38 is not currently installed and no compatible version is available. Please install this product or a compatible version.

How do I install this version because I thought I did so already?

Sorry, I was referring to the EPwm3Regs.TBCTL.bit.FREE_SOFT field. Try setting it to 2.

Can you check the IER registers (both in the PIE and the CPU) in the CCS registers view to confirm that the XINT is enabled properly?

If you go into your project properties and go to the Products tab on the General page, does it show both SYS/BIOS and TI-RTOS? Disable TI-RTOS if so. You only need SYS/BIOS for F2806x.

Whitney

I figured out that the print functions were taking up all the CPU usage which resulted in the delayed timing of the PWM. This explains why it was unstable in the debugger when the print function was active and stable when I was out of the debugger.

However, I am still having issues with the XINT functions. Here is my code setting up the registers

EALLOW;

GpioCtrlRegs.GPAMUX1.bit.GPIO12 = 0; // Use GPIO 12

GpioCtrlRegs.GPADIR.bit.GPIO12 = 0; // Set GPIO 12 as input

GpioCtrlRegs.GPAPUD.bit.GPIO12 = 0; // Enable pull-up for GPIO12

EDIS;

// GPIO12 is XINT1

EALLOW;

GpioIntRegs.GPIOXINT1SEL.bit.GPIOSEL = 12; // Set GPIO 12 as a XINT1 (external interrupt)

EDIS;

// Configure XINT1

XIntruptRegs.XINT1CR.bit.POLARITY = 0; // Falling edge interrupt

// Enable XINT1

XIntruptRegs.XINT1CR.bit.ENABLE = 1; // Enable XINT1 (external interrupt)

Here is a screen shot of the HWI.

As shown below, the register is setup correctly and the counter is running. So I don't know why it isn't working anymore now.

I'm not seeing any issues with your register configurations or Hwi setup. Did you check PIEIER1 and CPU the IER (in Core Registers) in the CCS registers view to confirm they are set?

Whitney

Where do I go to check those registers?

In the CCS Registers window, PIEIER1 is under PIE and IER is under Core Registers.

Whitney

IER Register

PIEIER1 Register

Are these registers correct?

PIEIER1 looks good (INT1.4 and 1.5 for XINT1 and XINT2 are enabled), but it INT1 in IER should be set to enable the whole INT1 group. SYS/BIOS should enable it for you. See if you're accidentally clearing it somewhere in the code?

Whitney

Thanks Whitney. All of your feedback has been very helpful. However, for the ecap module, I am feeding it a 500Hz signal and it doesn't seem to trigger the interrupt but when I remove and replace the pin to gnd at a steady rate, I see that the eCap function gets triggered. Is it possible that I need to drive the PWM signal from the board to ground through a MOSFET since it doesn't seem to work directing from the PWM pin I'm using?

It should be fine just to use a jumper wire to connect the two pins together on the LaunchPad. The PWM signal still looks okay on the scope? I thought in a previous post you had it working (or at least you were getting all the capture events) with the PWM? Or was it fine at 250Hz but not at 500Hz?

Whitney

I did some testing and found that the SensorMeasurementHWI() is getting called by eCAP3 but CAP1-4 are all the same value so when I do the difference equation my period and high period equal zero.

I have provided my HWI below that gets called by eCAP3. Why are CAP1-4 all the same exact value? I verified that I have a 500Hz 50%DC signal.

Void SensorMeasurementHWI()

{

unsigned int Measurement[2] = {0,0};

Measurement[HIGHPERIOD] = (unsigned int)ECap3Regs.CAP2 - (unsigned int)ECap3Regs.CAP1; // Calculate the PWM duty period (rising edge to falling edge)

Measurement[PERIOD] = (unsigned int)ECap3Regs.CAP3 - (unsigned int)ECap3Regs.CAP1; // Calculate the PWM period (rising edge to rising edge)

Mailbox_post(SensorMeasurement, &Measurement, BIOS_NO_WAIT);

ECap3Regs.ECCLR.bit.CEVT4 = 1;

ECap3Regs.ECCLR.bit.INT = 1;

ECap3Regs.ECCTL2.bit.REARM = 1;

PieCtrlRegs.PIEACK.all = PIEACK_GROUP4; // Acknowledge this interrupt to receive more interrupts from group 4

}

Here is the configuration of eCAP3 which is setup as a difference operation.

void InitECap3()

{

InitECap3Gpio();

ECap3Regs.ECEINT.all = 0x0000; // Disable all capture interrupts

ECap3Regs.ECCLR.all = 0xFFFF; // Clear all CAP interrupt flags

ECap3Regs.ECCTL1.bit.CAPLDEN = 0; // Disable CAP1-CAP4 register loads

ECap3Regs.ECCTL2.bit.TSCTRSTOP = 0; // Make sure the counter is stopped

// Configure peripheral registers

ECap3Regs.ECCTL2.bit.CONT_ONESHT = 1; // One-shot

ECap3Regs.ECCTL2.bit.STOP_WRAP = 3; // Stop at 4 events

ECap3Regs.ECCTL1.bit.CAP1POL = 1; // Falling edge

ECap3Regs.ECCTL1.bit.CAP2POL = 0; // Rising edge

ECap3Regs.ECCTL1.bit.CAP3POL = 1; // Falling edge

ECap3Regs.ECCTL1.bit.CAP4POL = 0; // Rising edge

ECap3Regs.ECCTL1.bit.CTRRST1 = 1; // Difference operation

ECap3Regs.ECCTL1.bit.CTRRST2 = 1; // Difference operation

ECap3Regs.ECCTL1.bit.CTRRST3 = 1; // Difference operation

ECap3Regs.ECCTL1.bit.CTRRST4 = 1; // Difference operation

ECap3Regs.ECCTL2.bit.SYNCI_EN = 1; // Enable sync in

ECap3Regs.ECCTL2.bit.SYNCO_SEL = 0; // Pass through

ECap3Regs.ECCTL1.bit.CAPLDEN = 1; // Enable capture units

ECap3Regs.ECCTL2.bit.TSCTRSTOP = 1; // Start Counter

ECap3Regs.ECCTL2.bit.REARM = 1; // arm one-shot

ECap3Regs.ECCTL1.bit.CAPLDEN = 1; // Enable CAP1-CAP4 register loads

ECap3Regs.ECEINT.bit.CEVT4 = 1; // 4 events = interrupt

}

I tried both of your suggestions separately and found that eCAP3 accurately measures the duty cycle at 50% with both implementations. However, when I vary the duty cycle, eCAP3 has a nonlinear behavior in have it measures the signal. For example, when I vary the duty cycle from 50% to 90%, the eCAP3 measures linearly up to 112% with an input DC of 70% then at an input of 71% the eCAP3 measures 3%. I see that the period counts stay the same but the high period counts is what affects these duty cycle calculation. So what is causing the inaccurate eCAP3 counts? I don't believe it is an overflow issue since this happens at the DC under 50% as well.

What are the other CAP values? Are they also incorrect in these cases?

Whitney

Yes the other CAP values are incorrect too after 71% DC. They just start counting back up from the 3% eCAP3 measurement at 71% DC.

Do you mind sharing a screen capture of your ECAP registers again, so I can see your updated configuration and all the CAP values?

Whitney

Initialization of eCAP3

void InitECap3()

{

InitECap3Gpio();

ECap3Regs.ECEINT.all = 0x0000; // Disable all capture interrupts

ECap3Regs.ECCLR.all = 0xFFFF; // Clear all CAP interrupt flags

ECap3Regs.ECCTL1.bit.CAPLDEN = 0; // Disable CAP1-CAP4 register loads

ECap3Regs.ECCTL2.bit.TSCTRSTOP = 0; // Make sure the counter is stopped

// Configure peripheral registers

ECap3Regs.ECCTL2.bit.CONT_ONESHT = 1; // One-shot

ECap3Regs.ECCTL2.bit.STOP_WRAP = 3; // Stop at 4 events

ECap3Regs.ECCTL1.bit.CAP1POL = 1; // Falling edge

ECap3Regs.ECCTL1.bit.CAP2POL = 0; // Rising edge

ECap3Regs.ECCTL1.bit.CAP3POL = 1; // Falling edge

ECap3Regs.ECCTL1.bit.CAP4POL = 0; // Rising edge

ECap3Regs.ECCTL1.bit.CTRRST1 = 1; // Difference operation

ECap3Regs.ECCTL1.bit.CTRRST2 = 1; // Difference operation

ECap3Regs.ECCTL1.bit.CTRRST3 = 1; // Difference operation

ECap3Regs.ECCTL1.bit.CTRRST4 = 1; // Difference operation

ECap3Regs.ECCTL2.bit.SYNCI_EN = 1; // Enable sync in

ECap3Regs.ECCTL2.bit.SYNCO_SEL = 0; // Pass through

ECap3Regs.ECCTL1.bit.CAPLDEN = 1; // Enable capture units

ECap3Regs.ECCTL2.bit.TSCTRSTOP = 1; // Start Counter

ECap3Regs.ECCTL2.bit.REARM = 1; // arm one-shot

ECap3Regs.ECCTL1.bit.CAPLDEN = 1; // Enable CAP1-CAP4 register loads

ECap3Regs.ECEINT.bit.CEVT4 = 1; // 4 events = interrupt

}

HWI that eCAP3 calls

Void SensorMeasurementHWI()

{

unsigned int Measurement[2] = {0,0};

Measurement[HIGHPERIOD] = (unsigned int)ECap3Regs.CAP3; // Calculate the PWM duty period (rising edge to falling edge)

Measurement[PERIOD] = (unsigned int)ECap3Regs.CAP3 + (unsigned int)ECap3Regs.CAP2; // Calculate the PWM period (rising edge to rising edge)

Mailbox_post(SensorMeasurement, &Measurement, BIOS_NO_WAIT);

ECap3Regs.ECCLR.bit.CEVT4 = 1;

ECap3Regs.ECCLR.bit.INT = 1;

ECap3Regs.ECCTL2.bit.REARM = 1;

PieCtrlRegs.PIEACK.all = PIEACK_GROUP4; // Acknowledge this interrupt to receive more interrupts from group 4

}

The screen capture above is showing roughly 50% duty cycle--was that correct or was it supposed to be something else?

I do see an issue with your Hwi function--an unsigned int is 16 bits but the capture values are 32 bits--you're losing the upper word when you write to your Measurement array.

Whitney

Yes i changed the definition to a 32 bit variable and now it seems to be working.