NRF Zephyr Timing SoC implementation - possible bug

RE: NRF Zephyr Timing SoC implementation - possible bug

Simon — Wed, 22 Sep 2021 13:49:19 GMT

I talked to a developer in Nordic with more knowledge about zephyr/soc/arm/nordic_nrf/timing.c, and he told me you should just go ahead an create a PR.

The guy assigned to Zephyr issue 37390 has not had time to look into it yet unfortunately.

Best regards,

Simon

RE: NRF Zephyr Timing SoC implementation - possible bug

davege — Wed, 22 Sep 2021 12:36:48 GMT

Hi Simon,

of course: https://github.com/zephyrproject-rtos/zephyr/issues/37390

RE: NRF Zephyr Timing SoC implementation - possible bug

Simon — Wed, 22 Sep 2021 11:54:44 GMT

Could you share a link to the Zephyr issue you created?

RE: NRF Zephyr Timing SoC implementation - possible bug

Simon — Mon, 20 Sep 2021 11:27:31 GMT

I just got back from holiday, and I will look into this the next days.

Best regards,

Simon

RE: NRF Zephyr Timing SoC implementation - possible bug

davege — Wed, 08 Sep 2021 07:20:44 GMT

Hello Simon,

hope you had good holidays.

Unfortunately, no one on Zephyr side picked up the issue I created, would you be able to have a look since it's Nordic specific code?

I'd be curious to know your comments.
Thanks!

Best,

RE: NRF Zephyr Timing SoC implementation - possible bug

Simon — Fri, 30 Jul 2021 09:13:12 GMT

Hello Davege,

I'm going on vacation for a long time now, so I won't be able to look into this unfortunately.

Would you be able to open a Zephyr issue? It will be seen by the people working on this driver (including many Nordic engineers), and you can get feedback whether your proposed solution is a valid one before opening a PR.

Best regards,

Simon

RE: NRF Zephyr Timing SoC implementation - possible bug

davege — Thu, 29 Jul 2021 07:34:57 GMT

Hi,

[quote userid="72692" url="~/f/nordic-q-a/77916/nrf-zephyr-timing-soc-implementation---possible-bug/322362#322362"]

since start and end are 32-bit values (just casted),

I do not understand this.

The start and end values are pointers of type timing_t, which is a typedef of uint64_t:

https://github.com/nrfconnect/sdk-zephyr/blob/0944459b5b622048a08ad1f8cf8a044c135fd0d3/include/timing/types.h#L10

[/quote]

With this I mean that start and end are detected using the soc_timing_counter_get function:

timing_t soc_timing_counter_get(void)
{
	NRF_TIMER2->TASKS_CAPTURE[0] = 1;
	return NRF_TIMER2->CC[0] * ((SystemCoreClock) / CYCLES_PER_SEC);
}

By nature, these are just 32-bit values (as the TIMER has resolution 32bits) multiplied by 4 and then returned into a uint64_t container.

If you try to detect average execution delta over time, you of course expect to end up in the situation I described, where:

start = large number, but coming first in time
end = small number, but coming last in time

What I think is happening is that overflow is not on UINT64_MAX boundary, but on a smaller value, as the max value you can have using soc_timing_counter_get is:

UINT32_MAX * 4 (which is << UINT64_MAX)

So I believe normal modulo arithmetic cannot apply here, and special handling of the overflow would be needed rather than just subtracting:

*end - *start

Hope this clarifies it, let me know if this is not clear still.

I'd like to get an opinion here before opening a PR and waste someone time...

Thanks!

RE: NRF Zephyr Timing SoC implementation - possible bug

Simon — Thu, 29 Jul 2021 07:18:09 GMT

[quote user=""] since start and end are 32-bit values (just casted), [/quote]

I do not understand this.

The start and end values are pointers of type timing_t, which is a typedef of uint64_t:

https://github.com/nrfconnect/sdk-zephyr/blob/0944459b5b622048a08ad1f8cf8a044c135fd0d3/include/timing/types.h#L10

[quote user=""]I discovered this by using a routines measuring an average of execution over time, as the problem is occurring only in the specific overflow cases.[/quote]

Since you do see unwanted behaviour, could you make a Zephyr (upstream) issue and explain your issue there?

Then it will be looked at by Zephyr developers