Kinetis Software Development KitのトピックRe: RTC vs FTM measurement

RTC vs FTM measurement

therealfreegeek — Sun, 14 Feb 2016 12:43:17 GMT

I have the RTC set up to give an interrupt every second, in the interrupt I reset the FTM counter and my software FTM overflow counter and then wait for an input capture. When I get the input capture I print (over USB-CDC) the time in hours, minutes, seconds and then the time to the input capture event in nano-seconds. The FTM is set up to be clocked at 50MHz so the tick is 20nS.

Thus the highest value I would expect to see in my "software" overflow counter before the "seconds" interrupt cleared it, would be 1/(65334 x 20nS) = 762

However I regularly see values over this, can anyone say why this would happen?

Here is the main code created with KSDK 1.3

//turns on seconds interrupt;

RTC_DRV_SetSecsIntCmd(rtcTimer1_IDX, true);

//Turn on the FTM counter in free running mode and enable overflow int

FTM_DRV_CounterStart(flexTimer1_IDX, kCounting_FTM_UP, 0x00, 0xFFFF, true);

//Turn on the FTM0 input capture

FTM_DRV_SetupChnInputCapture(flexTimer1_IDX, kFtmFallingEdge, FTM0_channel_1, input_filter_off);

for(;;){

if (FTM0_Ch1_ICflag == 1 )

{

FTM0_Ch1_ICflag = 0; // clears "input capture" flag set in FTM interrupt routine

cmd_get_datetime(); // prints the current date time

Ch1_nanoseconds_value =(((FTM0_Ch1_timer_overflow_count_store <<16) + FTM0_Ch1_capture_value)*20); // calculates the ns position of pulse this second

PRINTF("capture value%d\r\n", FTM0_Ch1_capture_value);

PRINTF("overflowcount %d\r\n", FTM0_Ch1_timer_overflow_count_store);

PRINTF("overflowcount x 65536 = %d\r\n", (FTM0_Ch1_timer_overflow_count_store<<16));

PRINTF("and %dns\r\n\n",Ch1_nanoseconds_value);

}
}

.....and here is the terminal view, with a couple of examples (second and last) with the overflow count significantly above 762, any thoughts?

Here are the two interrupt routines.

void RTC_Seconds_IRQHandler(void)

{

FTM0_timer_overflow_count= 0; //Resets my timer overflow counter back to zero

FTM_HAL_SetCounter(g_ftmBase[flexTimer1_IDX],0); //Resets the FTM counter back to zero

}

void FTM0_IRQHandler(void)

{

//checking the interrupt flag source and clearing

if(FTM_HAL_HasTimerOverflowed(g_ftmBase[flexTimer1_IDX]))

{

FTM_HAL_ClearTimerOverflow(g_ftmBase[flexTimer1_IDX]);

FTM0_timer_overflow_count++;

}

if(FTM_HAL_HasChnEventOccurred(g_ftmBase[flexTimer1_IDX],CHAN1_IDX))

{

FTM_HAL_ClearChnEventFlag(g_ftmBase[flexTimer1_IDX],CHAN1_IDX);

FTM0_Ch1_timer_overflow_count_store = FTM0_timer_overflow_count;

FTM0_Ch1_capture_value=FTM_HAL_GetChnCountVal(g_ftmBase[flexTimer1_IDX],CHAN1_IDX);

FTM0_Ch1_ICflag = true;

}

Thanks!

Re: RTC vs FTM measurement

Alice_Yang — Tue, 16 Feb 2016 07:19:49 GMT

Hello Ernest,

What about the chip number of your chip ?

And could you please show the code of how to configure the clock of the FTM0.

And please check whether it run to the interrupt function of RTC_Seconds_IRQHandler() and reset the counter ?

Hope it helps

Alice

Re: RTC vs FTM measurement

therealfreegeek — Tue, 16 Feb 2016 09:21:22 GMT

Hi, oops, it is running on the FRDM-K64F board, with SW3 configured as the input capture and the CDC on the second usb port and I used PE for the configuration set up of all the peripherals. I have attached the project which is mainly part of the RTC demo then a loop waiting for the input capture.

Re: RTC vs FTM measurement

Alice_Yang — Tue, 16 Feb 2016 10:17:51 GMT

Hello Ernest,

I have checked your code and test it , from the PE configuration , we can see you configure the

clock source of FTM0 60MHZ,

so we should change this 1/(65334 x 20nS) = 762 to 60MHZ/65334 = 918 .

And from your result , this is no "overflow count" more than 918 , and also in my test , there is neither .

Hope it helps

Have a great day,
Alice Yang

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

Re: RTC vs FTM measurement

therealfreegeek — Tue, 16 Feb 2016 11:24:52 GMT

Hi Alice, thanks for the insight, that would make sense, but please have a look at my MCG settings, they are set to have the system clock at 50MHz, but for some reason the FTM is saying that the system clock is 60MHz.

Is the FTM overwriting the settings from the clockMAN? Also, I can not seem to be able to change the FTM component inspector to 50MHz.

Re: RTC vs FTM measurement

Alice_Yang — Wed, 17 Feb 2016 03:07:01 GMT

Hello Ernest,

Please pay attention that , there are five clock configuration you can choose:

if you want use the mode 0, please configure it at here :

then in the FTM component , the clock source you can choose 50MHZ.

In your project , for you chose the mode 4:

we can see in the mode 4, the system clock is 60MHZ, so ....

Hope it helps

Have a great day,
Alice Yang

Re: RTC vs FTM measurement

therealfreegeek — Wed, 17 Feb 2016 14:47:51 GMT

Hi Alice,

Ahh, I had missed that, thank you very much for your help. I tried to change clockman_initconfig 4 to have a bus clock of 50MHz and a USB clock of 48MHz but this seemed not to be possible, is this correct?

I would prefer to operate at 50MHz bus rather than 60MHz bus as this makes the maths much faster as I can use a shift rather than a multiply.

Best Regards

Jim

Re: RTC vs FTM measurement

Alice_Yang — Thu, 18 Feb 2016 07:42:40 GMT

Hello Jim,

Yes, if you configure the bus clock to 50M, the best value to 48M of USB is configure to 50M.

Hope it helps

Have a great day,
Alice Yang

Re: RTC vs FTM measurement

therealfreegeek — Fri, 19 Feb 2016 09:27:18 GMT

Hi Alice, yes that is what I tried, however the closest frequency that could be generated for the USB was 50MHz with a 50MHz bus which caused an error.

For the time being it is not too big a problem for me to stay with 60MHz bus frequency which does allow a 48MHz clock for the USB.

Thanks again for your patience and support.

Re: RTC vs FTM measurement

Alice_Yang — Fri, 19 Feb 2016 09:41:22 GMT

Hello Ernest,

OK, welcome !

Alice

Re: RTC vs FTM measurement

mci — Tue, 02 Jan 2018 18:37:06 GMT

Hi Alice,

I thought I'd chime in on this old issue with my questions about FTM timer functions. Even though my issue & question is not exactly the same as the poster's problem I hope you will take notice & give me the answer.

I have taken over this FW on a product made by another SW vendor for the company I work for. The FTM timer is used for timing the motor movement from one position to the next based on MIN & MAX ranges in order for it to know what particular cycle it is on.

This MCU is capable of 64-bit and all KSDK FTM function parameters allow 32-bit time. However, whenever we increase the MAX value of a timer range to be >65536 milliseconds, e.g. 75000 msec, in order to accommodate slower motor movements, it times out. The motor power supply is operating at 60 MHz.

I do not yet understand all of FTM's function calls & computations so I can't figure out in this interrupt service routine quoted here below, where I should check & change in order to prevent the timer timeout.

Please let me know if you need any more info than this & what I have provided in order to be able to help me out.

Here's where it is failing; where it seems that it is returning a cut-off 16-bit timer captured_ms value instead the full 64-bit 70000 msec value.

Questions:

1. Why add 16-bit value of 65536 to capturecounts?

2. Why is the capture_ms value compared to 200 at the end? How is that value determined to be the limit?

Thanks for your help.

void capture_isr(void *data)

{

gcc_msg2 msg; // 12/26/17 mi new message structure has 32-bit arg parameter

//gcc_msg msg;

uint16_t i;

uint32_t CaptureTime_ms;

if(FTM_HAL_HasTimerOverflowed(g_ftmBase[VALVE_FTM_UNIT]))

{

FTM_HAL_ClearTimerOverflow(g_ftmBase[VALVE_FTM_UNIT]);

// Timer OverFlow add overflow count to captured time

CaptureCounts += 65536;

//printf("... Timer overflowed, CaptureCounts = %7lu\n",CaptureCounts);

}

else

{

for (i = 0; i < Valve_num_valves; i++)

{

if (FTM_HAL_HasChnEventOccurred(g_ftmBase[VALVE_FTM_UNIT], _valve_params[i].ftm_channel))

{

FTM_HAL_ClearChnEventStatus(g_ftmBase[VALVE_FTM_UNIT], _valve_params[i].ftm_channel);

CaptureCounts += FTM_HAL_GetChnCountVal(g_ftmBase[VALVE_FTM_UNIT], _valve_params[i].ftm_channel);

// Init FTM counter

FTM_HAL_SetCounter(g_ftmBase[VALVE_FTM_UNIT], 0);

//CaptureTime_ms = (CaptureCounts * 1000) / FTM_DRV_GetClock(VALVE_FTM_UNIT);

CaptureTime_ms = (CaptureCounts * 100) / FTM_DRV_GetClock(VALVE_FTM_UNIT);

CaptureTime_ms*= 10;

// 100ms debounce time

if(CaptureTime_ms > 200)

{

CaptureCounts = 0;

// send message to valve task

msg_prepare2(valve_get_task_id(), valve_get_task_id(), MSG_VALVE_INTERRUPT, CaptureTime_ms, &msg);

// msg_prepare(valve_get_task_id(), valve_get_task_id(), MSG_VALVE_INTERRUPT, (uint16_t)CaptureTime_ms, &msg);

_lwmsgq_send(valve_get_msg_queue(), (_mqx_uint *)&msg, 0);

}