CCS/TMS320F28035: Standalone mode problem - Delay in ISR trigger

Sagar,

If I understand you correctly, your code is running slower stand-alone rather as compared to emulation mode. Also, it runs slower in flash than RAM. Typically RAM is the fastest execution, but did you set up the flash wait-states? Perhaps the following workshop might help you:

processors.wiki.ti.com/.../C2000_Archived_Workshops

See module 10 and lab 10 exercise (note flash.c file).

I hope this helps. If this answers your question, please click the green "Verified Answer" button. Thanks.

- Ken

Hi Ken,

I already changed as per lab 10 exercise (flash.c). So my question is that how can I make it to run as per emulation mode speed. I have time critical application. So can you suggest what should I do?
I also added Epwm ISR to #pragma to copy it to ram function.

Sagar,

Please be sure to follow the additional steps in Lab 10 besides just adding the flash.c file. All time critical code should be copied from flash to RAM to execute at maximum speed.

I hope this helps. If this answers your question, please click the green "Verified Answer" button. Thanks.

- Ken

Yes I have already added Time critical Sections to RAM! But is there a relationship between FLASH and EPWM? I mean latency to trigger?

Sagar,

Could you please give more details on how you are using the ePWM module to trigger an ISR? Thanks.

- Ken

I set Epwm1Regs.TBPRD to different values for pwm modulation.

So my observation is that for same code in standalone mode it takes nearly 4 -5 factor more time than in emulation mode for same value of TBPRD. I have gpio to observe that.

Sagar,

If I understand you correctly, you using the ePWM period value to modulate the waveform (rather than a compare register value). Does this mean you have fixed values in the compare register to change the output pins? What are you using to generate the interrupt for the ISR (CTR=PRD, etc.)?

Also, I know that you have added the flash.c file to your project. But, did you add the function call to main()?

//--- Initialize the Flash and OTP
InitFlash(); // Initialize the Flash

- Ken

Hi Ken-

Yes, I have added InitFlash(); function call to main().
In Epwm I have this following initialization and then I vary TBPRD value :-

EPwm1Regs.TBSTS.all=0;
EPwm1Regs.TBPHS.half.TBPHS =0;
EPwm1Regs.TBCTR=0;
EPwm1Regs.CMPCTL.all=0x50;
EPwm1Regs.CMPB=0;
EALLOW;
SysCtrlRegs.PCLKCR1.bit.EPWM1ENCLK = 1;
EDIS;
EPwm1Regs.AQCTLA.all =0x00;
EPwm1Regs.AQCTLA.bit.ZRO =0x02;
EPwm1Regs.AQCTLA.bit.PRD =0x00;

EPwm1Regs.AQCTLA.bit.CAU =0x01;
EPwm1Regs.AQCTLB.all=0x09;

//EPwm1Regs.AQCTLA.all=0x60;
//EPwm1Regs.AQCTLB.all=0x09;
EPwm1Regs.AQSFRC.all=0;
EPwm1Regs.AQCSFRC.all=0;

EPwm1Regs.ETSEL.all=0x0A;
EPwm1Regs.ETPS.all=1;
EPwm1Regs.ETFLG.all=0;
EPwm1Regs.ETCLR.all=0;
EPwm1Regs.ETFRC.all=0;

EPwm1Regs.PCCTL.all=0;

EPwm1Regs.TBCTL.all=0x0010+TBCTLVAL;

Hello,

I'm responding on this thread so we don't have a duplicate one going.

Do you have other ISRs in this system that have this same issue of latency? When you say emulation mode, what do you mean? Do you mean running from RAM or is it the exact same .out that you're running in standalone but just running with the debugger connected?

Can you take a look at some of the causes of ISR latency on this wiki page and consider if you have any of them in your code?
processors.wiki.ti.com/.../Interrupt_FAQ_for_C2000

Whitney

I just have one ISR.

Emulation means running from FLASH without standalone mode.
I did look at this link but not sure if anything causes this.

So you're using the same .out both in emulation mode and standalone mode?

Whitney

Yes I am using the same.h File.

Also I have on question regarding updating TBPRD value.
I have my EPWM isr triggered at the end of EPWM ISR. So when It triggers at TCNT = TBPRD, I will update my TBPRD register with new value.
So If I try trigger my EPWM ISR to at TCNT = 0, Would it make any difference?

I am Sharing images of Picoscope.

Image 1:Epwm Pulse with varying TBPRD in flash (not standalone)

Image 2:Epwm Pulse with varying TBPRD in Standalone mode

Image 3:   Epwm Pulse with constant TBPRD in Standalone mode

So can you explain is there any relation that when I vary TBPRD in my stand alone code there is this weird behavior?

Sagar - can you get an image of : Epwm Pulse with constant TBPRD in emulation mode (in flash, not stand-alone)?
What are you locking your PLL at? With fixed TBPRD do you see proper pulse freq at emulation or stand-alone?

I want to understand if you see problem with both fixed and varying TBPRD results between emulation (With CCS, running from flash) and Stand-alone (without CCS, running from flash).

I'm assuming that in stand-alone mode you are not having CCS connected but just booting to flash application and in emulation mode you are running from flash but with CCS connected.


Best Regards
Santosh Athuru

Hey Santosh,

Your Assumption about is right above this.
"I'm assuming that in stand-alone mode you are not having CCS connected but just booting to flash application and in emulation mode you are running from flash but with CCS connected. "

I have similar result for Epwm Pulse with constant TBPRD in Standalone mode and Emulation mode.

I will check PLL and post it but I think the I did configure to have SYSClock at 60 MHZ.

sagar shah54 said:

Yes I am using the same.h File.

Also I have on question regarding updating TBPRD value.
I have my EPWM isr triggered at the end of EPWM ISR. So when It triggers at TCNT = TBPRD, I will update my TBPRD register with new value.
So If I try trigger my EPWM ISR to at TCNT = 0, Would it make any difference?

Sagar- in addition to the questions above post, please let us know about below .

I believe Whitney was asking if you are using the same .OUT file in both stand-alone and emulation runs. She isn't asking about the .h file, but thanks for the info.

Also can you clarify what you mean by EPWM isr triggered at the end of EPWM ISR? 

You can generate interrupt at ZERO or period match or both among other possibilities, but between the zero and period match options the freq of the ISRs being triggered shouldn't change if the PWM counter settings aren't changing. 

Best Regards

Santosh Athuru

sagar shah54 said:

I have similar result for Epwm Pulse with constant TBPRD in Standalone mode and Emulation mode.

I will check PLL and post it but I think the I did configure to have SYSClock at 60 MHZ.

Sagar,

By similar result, can you clarify that you see good result or variance between stand-alone and emulation runs? Does the pulse frequency match the calculations?

Best Regards

Santosh Athuru

I meant that EPWM ISR is triggered at the When Tcount = TBPRD.
Inside this EPWM isr I update TBPRD value as I am changing the Frequency for the next PWM cycle.

And Yes, I am using the same.out file. just switching from emulation mode and standalone mode

I Find good results at constant value of TBPRD. But if I change that, then it works fine in emulation mode and does not work in standalone mode!

Sagar,
thanks for confirming that the results are good and same for the Constant value of TBPRD for both emulation and stand-alone runs. This makes sense, there should be no difference between the stand-alone and emulation runs for the scope and environment you have.

Now for the varying TBPRD, how are you capturing and comparing the wave forms, how do you know that you are looking at the wave forms at the same instant in time from power up or program begin? Since this is a program that is running on the Silicon on power up in stand-alone mode, how do you know that the instant of scope wave form in stand-alone mode is being compared to the same instant of the scope wave form from emulation mode? I suppose that the variance of the TBPRD is not constant right?


Best Regards
Santosh Athuru

I have a gpio triggered when I start my epwm pulsing.
I use this as a trigger to record on the scope.

regards
Sagar

Hey Santosh,

I will update you about it in next week.
Thanks!

You mentioned about using RAM, but did you make sure to call 'memcopy()' to copy the critcal code to RAM?

If you have resolved the issue already, let us know.

Sagar,

It's been a week since we have heard from you last. Therefore, we are assuming you were able to resolve your issue. If this isn’t the case, please reject this resolution or reply to this thread. If this thread locks, please make a new thread describing the current status of your issue. Thank you.

- Ken

I Still have this problem. But I am not able to do Tests mentioned by Santosh as I am working on some other project right now.
Will get back as soon as I start this project again.