F28069 HRCapture

Brian,

There is a potential issue with the HRCAP calibration function getting stuck.  As a work-around, please call the function no more than once every 1600 cycles, within the loop.  

However, the first time you perform calibration during system start-up (before enabling things like interrupts and the main loop) should typically complete without issue.  Let me know if this is not the case for you.

If you skip calibration, can you access the HRCAP module?

On F28069, the HRCAP module is clocked using a separate PLL system.  Did you properly configure that?

Regards,
Daniel

As a simple test, using the example project provided within ControlSuite, comment out the continuous calibration loop found within the for loop.  If you do this, the example project should run without issue.

// Run calibration routine periodically in background using HRCAP1 internally tied to HRPWM8 output.

status = 0; // New calibration not complete
while (status!=2) // While calibration is incomplete
{
    status = HRCAP_Cal(1,HCCAPCLK_PLLCLK, &EPwm8Regs);
    if (status == HCCAL_ERROR)
   {
      ESTOP0; // If there is an error on HRCAP, stop and check 98 MHz < PLL2CLK < 120 MHz .
   }
}

Daniel,

I do attempt to run the calibration before enabling interrupts but I do have it in the main loop. However even calling before enabling interrupts it still only returns "in progress" but I will change my code and try in outside the main loop.

I am using a TMX320F28069PZA (controlCARD).

If I skip the calibration I still cannot access the HRCAP module.

Many thanks,

Brian

Brian,

Calling calibration within the main loop should be fine.  Please see my second post about running the example project.

Also, please double check the clocking used.

Regards,
Daniel

I cannot run the example. It compiles fine but when I take it into debug it looks for some MSP430 directory/file with a .ccxml extension and immediately bails out. I will try the calibration routine in my development code.

Brian

Double check that you are using a correct Target Configuration.

Daniel,

I get change the target configuration and got the example to compile and run...same results as my development code, always "in progress."

Also moved the calibration call outside the main loop with no success. Should I try a delay?

In the build/target configurations there does not exist a TMX type part which is on this controlCARD, only TMS. I understand the TMX is an experiemental part, does this potentially matter? 

Brian

Brian,

Can you elaborate on what you mean by 'always "in progress"'?

The calibration routine does not complete in a single function call.  

It is designed to be called repeatedly until it returns a value of 2, signalling completion (this is why it has to be called from within a while loop).  If you care, it takes about 250 function calls to complete.

Regards,
Daniel 

Daniel,

I my development code I have the calibration call setup much like the example, where it calls the function until the status returned is "complete" although I have not put a loop counter in to see how many iterations was actually called. But I am pretty sure it has not been called that many times. I will retry...

Will the calibration prevent register access?

Many thanks Daniel,

Brian

Daniel,

I put a counter in the while loop for the calibration function call. It appears to be called tens of thousands of times with the function still only returning the "in progress" status.

Many thanks,

Brian

Eureka success! With the calibration at least. In my device init file I had disabled most of the peripherial clocks in order to save power. I enabled them all and it worked. Looks like I have register access too.

Many thanks!

Brian

Daniel,

I still find that I cannot clear and flags in the HCIFR by setting the appropriate bits in the HCICLR. The soft reset does seem to clear all but the counter overflow and likewise if I manually enter a value in HCICLR via the watch window.

I am also confused why I am generating these interrupt flags, as in my configuration of the HRCapture module I only enable the falling edge capture interrupt. So I end up with the interrupts for counter overflow and rising edge not enabled, but generating interrupts and not able to clear them.

Any thoughts?

Many thanks,

Brian

Brian,

For this module, the interrupt flags are generated each time the corresponding event occurs.  However, the interrupt itself is not issued to the PIE unless enabled in the HCCTL register.

How are you trying to write to the HCICLR register?  Are you using the proper bit field structure notation?  

Here is a code example:
HRCap4Regs.HCICLR.bit.FALL=1; // Clear FALL flag
HRCap4Regs.HCICLR.bit.RISE=1; // Clear RISE flag

Regards,

Daniel

Daniel,

I agree that the interrupt itself should not be issued unless the corresponding bit is set in the HCCTL register.

Here is how I enable only the fall event interrupt and I call this in an Init() function after calibration.

HRCap1Regs.HCCTL.bit.SOFTRESET = 1; // Soft reset to clear counter and interrupt flags.

HRCap1Regs.HCCTL.bit.HCCAPCLKSEL = 1; // Select PLL2 output for HCCAPCLK.

HRCap1Regs.HCCTL.bit.FALLINTE = 1; // Enable falling edge interrupt.

HRCap1Regs.HCCTL.bit.RISEINTE= 0; // Disable rising edge interrupt.

HRCap1Regs.HCCTL.bit.OVFINTE = 0; // Enable HRCap counter overflow interrupt.

In the interrupt routine I do attempt to clear the flags (even though I do not set them in the HCCTL in the init) using the HCICLR and the code I use is:

HRCap1Regs.HCICLR.bit.FALL = 1;  // Clear fall flag.

HRCap1Regs.HCICLR.bit.RISE = 1;  // Clear rise flag.

HRCap1Regs.HCICLR.bit.RISEOVF = 1; // Clear rise overflow flag.

HRCap1Regs.HCICLR.bit.COUNTEROVF = 1; // Clear the counter overflow flag.

HRCap1Regs.HCICLR.bit.INT = 1;   // Clear HRCapture interrupt flag. 

But the flags don't seem to change state, unless I call a soft reset.

Why am I getting intterupt events like rise and counter overflow when I don't even set them in the HCCTL? I have looked at the contents quite a few times and it is always 0x0104 which is right according to my Init() function.

Any why will the flags not clear even though I am using the correct bit field structure? I am pretty much dead in the water because I constantly interrupts with event I don't set and then I can't clear them.

Many thanks,

Brian

As I stated in my previous post, the interrupt flag register bits are set each time the corresponding event occurs.  If there is a rising edge captured by the module, the RISE interrupt flag will be set.  It does not matter if the interrupt is not enabled in the HCCTL register.  

If it helps, think of the HCIFR as an event indication register.

However, even if the HCIFR bit is set, the interrupt is not issued to the PIE unless the interrupt is enabled in the HCCTL register.

Regarding the registers not clearing, try enclosing the writes within an EALLOW/EDIS bracket, as exampled below.

EALLOW;

HRCap4Regs.HCICLR.bit.FALL=1; // Clear FALL flag
HRCap4Regs.HCICLR.bit.RISE=1; // Clear RISE flag

EDIS;

Also, having extra interrupt flags active will not affect the behavior of your ISR.  Only the interrupt enabled in the HCCTL register will trigger an ISR and only that bit needs to be cleared.

You mentioned that your system is constantly interrupting.  Are you also clearing the appropriate PIE group INT flag?

Example below:

HRCap4Regs.HCICLR.bit.INT=1; // Clear HRCAP interrupt flag
PieCtrlRegs.PIEACK.bit.ACK5=1; // Acknowledge PIE Group 5 interrupts.

Daniel,

I appreciate your clarification, because yes I did not understand that point from our previous discussions.

It is still quite misleading that all the flags would be set in a flag register even when they are disabled. It is troubling that everytime the code now enters the ISR, several flags for the module can be set yet I am depending on the FALL flag being the only one which triggered the interrupt and that the data is valid.

I will add the EALLOW/EDIS commands to my ISR and verify it does clear the interrupt in the flag register. Thank for very much for your time in this matter Daniel, hopefully this is the last little hurdle.

Brian 

Thanks for your message.

In the past I have some problems with HRCAP Calibration, I have tryed all of the example and do some test always with the same issue. HRCAP Calibration getting stuck with In Progress result.

So, I have made some changes in my code. Just for test, I have created a 1 kHz timer setting a flag in order to call the HRCAP Calibration function in my main function.

And I have removed the while () for the calibration call.

I have incremented a counter to count the number of call needed to successfully calibrate the HRCAP. And I have also incremented an another counter to count the calibration success.

Then I have traced these information on SCI (RS-232) to see how it works in real time.

Now the calibration function need to be called 256 times (this number doesn't change to have a success for calibration routine), and I have the success counter incrementing.

Eureka, now it seem's to work fine, I have read and read and read the documentation, I have tryed a lot of things to make this calibration working as expected.

Thanks for your message, I think TI MUST update the HRCap documentation, and also update the example code, they are not correct and need more information !