This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Would calculation affect timer

I am using a power profiler to measure the timing of my program and I found something wrong. So I tested with a simple pure timer.

So first I set the timer during to 300ms

#define half_epoch_during		APP_TIMER_TICKS(300)
err_code = app_timer_create(&half_epoch_timer, APP_TIMER_MODE_SINGLE_SHOT, half_epoch_timer_handler);
err_code=app_timer_start(half_epoch_timer,half_epoch_during,NULL);

And I did nothing in the callback function

static void half_epoch_timer_handler (void * p_context)
{}

The timing is all right. I measure a periodic change in current every 300ms. Then I add a for loop to simulate calculations in the callback function.

static void half_epoch_timer_handler (void * p_context)
{
	int d;
	for (int i =0; i<3000000; i++)
	{	
		d = i;
	}
}

And now, the timing is wrong. I can measure a current change every 240ms. So my question is why would calculation make the timer shorter?

ps: My board is nRF52840 PDK.

  • You are correct. You are defining the tick rate.

    On the for loop, I think it is minimum 6million opcodes since you force it to write i to d. Or about 93 msec to execute.

    It is an interesting problem. Still I would probably choose to let it keep track of time and see if it does that correctly while running the for loop.

  • Or so you don't have to interface to the device, just have it toggle a gpio and then you can measure the rate with an o-scope. I would assume you will see some jitter in the basic timing since the ble stack has highest interrupt priority but the basic rate should still be 300msec.

  • Hi @mich_x. Did you solve the issue? If not, can you post a screenshot of your current measurements? I did a quick test with a logic analyzer and the timer handler seems to be called at ~300ms with or without your calculations inside it.

  • No, I have not got time to work on this. Did you add Softdevice when you run the test? I think I have to run the test on top of the S14.

  • I have tested with PCA10056 running the app_ble_template example and S140 v5.0.0-2.alpha and I'm still not able to reproduce this. With a logic analyzer I can still see that the interrupt triggers at 300ms intervals. With the PPK though, I do see some variations in the order of 10-20ms. However, I talked to the PPK HW guy, and he told me that this is to be expected because the time axis in the PPK software is not that accurate. Especially if you are running the software on Windows 10.

Related