FTM changing FTMx_CxV within ISR

[dougprice]

On a K64 I'm using a timer channel as a software timeout. Normally events occur in "main line" and the values operate as expected.

When the time expires the ISR performs an operatian the updates the FTMx_CxV with a new value. On reading back the register the value appears changed but the timer value does not operate.

I'm sure its a simple setup & control issue but on reading the doumentation I find no clear answer (that I understand).

Suggests?

Thanks

Doug

[jeremyzhou]

Hi Doug,

I'm glad to hear that you had figured out the root cause of the issue.

If you have any further questions about it, please feel free to contact with me.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[dougprice · Accepted solution]

As expected, something dumb.

I stumbled over a control variable because of the cyclical nature of the operation.

Once I re-read the manual for the n-th time and convinced myself it should work I just bached my head against it until the wall cracked. After that it was easy.

The timer works as expected.

Cheers.

[jeremyzhou]

Hi Doug,

After had a brief look thorough the statement, I'm still a little confused with our question.

I was wondering if you can clarify the sentence "On reading back the register the value appears changed but the timer value does not operate" and what "the timer value" stand for.

I'm looking forward to your reply.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[dougprice]

Hi Ping

The process I've used (for years on HC, and Coldfire processors)  is to configure the main FTM counter in a simple rollover mode, in this case counting up. To set a channel for a timeout (in the future), the timeout interval (in timer ticks/counts) is added to the current value of FTM0_CNT value, that sum is written to FTM0_C0V as the new "timer value" (maybe I should have said time value).

If my expected operation happens, firmware again sets FTM0_C0V = FTM0_CNT + interval. And the cycle begins anew.

If the operation does not occur, the ISR triggers, but again it sets FTM0_C0V = FTM0_CNT + interval. This is the thing that does not work. In both cases the same function is used to set the new interval.

While debugging this operation I dumped values out my diagnostic port, as part of that, after writing FTM0_C0V I read it back, it "appears" to be written in all cases but as I mentioned, it looks like it works when I do it in main line code but not when I do it from within the ISR.

My code snippet is below. The TimeOutEvent_Xxxx() functions are all unmodified PE driver functions, cliPrnXxxx() are my diagnostic prints.

    CurrentTicks     = TimeOutEvent_GetCounterValue( NULL );
    OffsetTicks      = CurrentTicks + ( interval * TIMEOUT_1_MSEC_COUNT );

    TimeOutEvent_SetOffsetTicks( NULL, channel, OffsetTicks );

    cliPrnUInt32( CurrentTicks  );
    cliPrnUInt32( OffsetTicks );

    TimeOutEvent_GetOffsetTicks( NULL, TIMEOUT_CHANNEL_START_TX , &OffsetTicks);
    cliPrnUInt32( OffsetTicks );

This should be simple, I've likely done something really stupid, and I will be truly embarased once we figure it out. What I need is someone to ask the pointy questions to push me in teh correct direction.

I appreciate your help.

Doug