TimerInt, FreeCnt, etc. calling Disable() method disables entire TPM module.

[jgirard1]

For HCS08...

Why do TimerInt, FreeCnt, etc. components disable the entire TPM counter module when calling the Disable() method?  This prevents other shared components on other channels from functioning correctly because the shared timer is stopped from clocking.

static void HWEnDi(void)
{
  if (EnUser) {
    TPM2SC |= 0x10;                    /* Run counter (set CLKSB:CLKSA) */
  } else {
    /* TPM2SC: CLKSB=0,CLKSA=0 */
    clrReg8Bits(TPM2SC, 0x18);         /* Stop counter (CLKSB:CLKSA = 00) */  <--This disables the clocking
    /* TPM2CNTH: BIT15=0,BIT14=0,BIT13=0,BIT12=0,BIT11=0,BIT10=0,BIT9=0,BIT8=0 */
    setReg8(TPM2CNTH, 0x00);           /* Clear counter register - any write clears complete counter */
  }
}

Since these components use the Output Compare to generate their interrupts, why not just disable the compare operation using ELSnB:ELSnA bits and keep the timer running for other shared components?

I tried changing the property: [Component uses entire timer = No] ...and this doesn't help.

I also tried always keeping the component enabled and then using the EnableEvent() method to control the action.  The problem with this is it still keeps the output compare interrupts running when the event is disabled.  The event call is just blocked when disabled.  This is very inefficient.  If the envent is disabled, then why not disable the output compare altogether if it is not required?

[jgirard1]

So far everything appears to function correctly.  Thank you.

[jgirard1]

This hot fix fixed the other hot fix.  All is well now.  Thank you again!

[jgirard1]

Hello again.  Have you been able to come up with a resolution to the bug in the hotfix you gave me?  I cannot us the hotfix as-is.  It is generating code for a variable "...EnEvent" that does not exist and this causes the code not to build.  I need to comment out the code line in CPU.C, each time just to get the code to build. It is very inconvenient.  Thank you.

[jgirard1]

This issue is with Processor Expert auto-generating code into the CPU.c file that no longer not exist, specifically into the pe_low_level_init() function.

  FSKOut_Out_IRQ_EnEvent = FALSE;       /* Disable events */   <-- EnEvent variable is supposed to be removed.

1. I have delete the enitre CPU.c file, built the code and it failed because the CPU.c file was erased.

2. Next, I had Processor Expert regenerate all the files and CPU.c file came back with the same extra code that is not supposed to be there.

3. I built the code again and of course it fails because there is code in there with an unknown variable reference.

The code is definitely coming back over and over, each time I try to delete it, it is auto-generated again.

When I include a new FeeCntr component, I set Interrupts enabled, OnInterrupt() event method selected, "Enable Events in Init Code" turned off and then I have EnableEvent and DisableEvent methods selected to be generated.

Here is another problem:

When I use PITload0 as the timer source, Processor Expert errors out and fails to generate code, saying that I need to contact Freescale Support.  I am using MC9S12XA256 processor.

I have tried this over and over adding a new component each time and it gives the same errors under all the above listed conditions.

[jgirard1]

I am using CodeWarrior Development Studio S12(X) Version 5.1, Build 10221 (Professional).

If I can have this same fix for S12(X), that would perfect.  Thank you for all your great help.

[ProcessorExpert]

Hello,

I am sorry, I have not reproduced such behaviour. I have tried to use two TimerInt components in shared mode on the TPM2 (DZ128) and I have got this code:

static void HWEnDi(void)
{
  word TmpCmpVal;                      /* Temporary variable for compare value */

  if (EnUser) {
    TmpCmpVal = (word)(TPM2CNT + CmpVal); /* Count current value for the compare register */
    TPM2C1V = TmpCmpVal;               /* Set compare register */
    while (TPM2C1V != TmpCmpVal) {}    /* Wait for register update (because of Latching mechanism) */
    /* TPM2C1SC: CH1F=0 */
    clrReg8Bits(TPM2C1SC, 0x80U);      /* Reset request flag */
    /* TPM2C1SC: CH1IE=1 */
    setReg8Bits(TPM2C1SC, 0x40U);      /* Enable compare interrupt */
  } else {
    /* TPM2C1SC: CH1IE=0 */
    clrReg8Bits(TPM2C1SC, 0x40U);      /* Disable Compare interrupt */
  }
}

Could you please be more specific? What particular settings, compoennt leads you to your issue? What verison of PE are you using? Publishing a demonstration project would be the best.

Anyway, I agree with your last paragraph. I will pass this to developers to consider improving generated code in some next release.

best regards
Vojtech Filip
Processor Expert Support Team

[jgirard1]

I have duplicated the issue again.  You need to use FreeCntr.  If you use FreeCntr and source it to a TPM device that also has other counters sourced (TimerInt, etc.) on the other TPM devices, FreeCntr will no longer allow you to disable the component.  It says that the component cannot be disabled because it is sourced from a shared timer.  The only thing you can do with FreeCntr is to disable the event.  The Output Compare interrupt will still occur in the background.

TPM10 - TimerIntt

TPM11 - Timeline

TPM12 - FreeCntr <-- (Cannot be disabled)

TPM13 - Unused

Since all these counters are based on the individual Output Compares of the TPM unit, they can easily be disabled by turning off the Output Compare interrupt.  There is no issue doing this when you are only using all TimerInt components.  As a matter of fact, you can disable the TimerInt's on the same TPM unit as the FreeCntr, but yet FreeCntr cannot be disabled?  Why not?

I believe there is a design problem with the FreeCntr components.  There is some major oversight here.  Is there a good reason why these FreeCntr components act this way?  Is there an easy way to get it fixed?

The problem could easily be resolved by creating my own FreeCntr componet that works, but the major issue here is there is no way to get access to the Processor Expert timer database for error checking, configuring etc.  The only way to do that it is use inheritance and that has its own set of drawbacks.  Primarily, you will usually need to inherit from a timer component or some other thing that is buggy, has limitations or some other stupid set of issues that ultimately make it impossible to acheive your goal.  So either way, I lose.

[ProcessorExpert]

Hello,

we are working on improvent of the behavior of Enable/DisableEvents in TimerInt, FreeCntr, TimerOut components for HCS08/CFV1 families. For now as a possible workaround you can disable code generation of selected component and change the code manually, see below:

/header/

#define TI1_EnableEvent() (TI1_EnEvent = TRUE, FTMxCxSC_CHxIE = 0x01, (byte)ERR_OK) /* Enable interrupt, set the flag "events enabled" */

In case it will not work for you, we can provide hot-fix for CW V10.2 (PE V5.3) that will contain  the fix of Enable/DisableEvents.

Regarding disabling of the FreeCntr, the problem is that if the timer is shared, the counter cannot be stopped, which would be what ‘disable‘ method would need to do. So it’s not available in shared mode. It’s described in the hint  of the method:

„Disable - This method disables the component, i.e. timer is disabled and the internal clocks are stopped. Last counter value is usually preserved in the counter (if it is supported by HW).
The method is not available if the counter is shared.“

best regards
Vojtech Filip
Processor Expert Support Team

[jgirard1]

I am using CodeWarrior V6.3 PE with V3.09 Service Pack.  Is there a HotFix for this version?

I understand that the Disable method stops the counter.  My complaint is that it is wrong to do so.  I believe there is no reason to stop the counter.  Just stop the interrupts from occurring if it is an Output Compare.  The TimerInt works this way.

I just had the issue again.  I am using two FreeCntr components shared within the same TPM module and there are conflicts that prevent me from using the components the way I want to.  So I try to use TimerInt instead for compatible functionality, but that doesn't work either because TimerInt does not give you direct access to setting the period based on raw timer ticks via a SetCompare().  All you get are these high-level math intensive calculating methods that are just not applicable and are inefficient.

One thing FreeCntr is missing is a method to get the compare value GetCompare().  If you have this method, you can read the last interrupt time add an offset then use SetCompare() to set a new periodic interval.  As it stands now, the periodic interval is static and can only be established once from the component properties.

FreeCntr is pretty low-level to allow you to do many things at will, but it is lacking a couple of things to make it completely versatile at controlling a periodic interrupt simply and easily for anyone and any application.  Perhaps this is not the purpose of FreeCntr, which I can accept, but please tell me of another component that is closer that allows me to freely set a variable periodic interrupt or create a simple variable timeout with optional interrupts that I can enable and disable.  There is nothing.

[jgirard1]

I am using CodeWarrior V6.3 PE with V3.09 Service Pack.  Is there a HotFix for this version?

I understand that the Disable method stops the counter.  My complaint is that it is wrong to do so.  I believe there is no reason to stop the counter.  Just stop the interrupts from occurring if it is an Output Compare.  The TimerInt works this way.

I just had the issue again.  I am using two FreeCntr components shared within the same TPM module and there are conflicts that prevent me from using the components the way I want to.  So I try to use TimerInt instead for compatible functionality, but that doesn't work either because TimerInt does not give you direct access to setting the period based on raw timer ticks via a SetCompare().  All you get are these high-level math intensive calculating methods that are just not applicable and are inefficient.

One thing FreeCntr is missing is a method to get the compare value GetCompare().  If you have this method, you can read the last interrupt time add an offset then use SetCompare() to set a new periodic interval.  As it stands now, the periodic interval is static and can only be established once from the component properties.

FreeCntr is pretty low-level to allow you to do many things at will, but it is lacking a couple of things to make it completely versatile at controlling a periodic interrupt simply and easily for anyone and any application.  Perhaps this is not the purpose of FreeCntr, which I can accept, but please tell me of another component that is closer that allows me to freely set a variable periodic interrupt or create a simple variable timeout with optional interrupts that I can enable and disable.  There is nothing.

[ProcessorExpert]

Hello,

please find the attached archive that contains the improved code of Enable/DisableEvent methods for FreeCntr, TimerInt, TimerOut components. These methods are influencing the interrupt directly now. I think that it should solve most of your problems.

The instruction how to apply the hot-fix are described in the readme.txt in the archive.

best regards
Vojtech Filip
Processor Expert Support Team

[jgirard1]

This fix is a good attempt at the right approach, but it still has one major flaw.

Upon enabeling the event (which now re-enables the interrupt), you can get an immediate interrupt if a compare occured while the interrupt was disabled.

The Enable function needs to also clear the interrupt flag before enabeling the interrupts.  There is no other method available to do this, other than GetStaus(), which of course is disabled when using interrupts, so it must come from the driver code itself.

[ProcessorExpert]

Hello,

yes, you are correct. I will prepare the update as soon as possible.

best regards
Vojtech Filip
Processor Expert Support Team

[jgirard1]

The other thing you also need to add to the logic is an interlock to check if the event is already enabled.  You can simply test the CHxIE bit.  If the CHxIE bit is set, then do not clear the interrupt status flag.  This is because the user code may always call the EnableEvent() method.  There should be no side effects from calling the EnableEvent() method more than twice in a row if it is already enabled.  You do not want to inadvertently clear the interrupt status flag before it can be serviced, especially when interrupts are disabled.

Please let me know how I can join the development team.  I have many more ideas and I know how to develop new components using Component Wizard.

[ProcessorExpert · Accepted solution]

Hello,

please find the attached updated hot-fix.

Regarding: "Please let me know how I can join the development team.  I have many more ideas and I know how to develop new components using Component Wizard."

We appreciate your offer for cooperation, I have passed that to my manager.

best regards
Vojtech Filip
Processor Expert Support Team