Join GitHub today
k_busy_wait exits early on Nordic chips #11626
Further, for NRF52840 k_busy_wait delays:
Timings derived from a custom application with a GPIO toggle before and after the delay, duration measured with Saleae Logic Pro-8.
That really short delays take much longer than they should is unfortunate. That longer delays take shorter than they should is simply unacceptable. We must have a reliable usleep functionality to satisfy hardware timing requirements.
I did find issue #6498 which was enlightening but did not provide a solution.
Some improvement might be accomplished by fixing k_busy_wait to account for cycles lost to integer truncation, though a 10% error in a 100 us delay is difficult to understand. However, I'm fixing it another way in a PR to be submitted next.
referenced this issue
Nov 23, 2018
@carlescufi As a consequence of #14991 reverting this change the misbehavior is again present in Zephyr 1.14 and current master. Re-testing on nRF52840 shows 50 us delays complete in 24 to 32 us, 75 us delays in 55 us, and 100 us delays in 86 us tested on 1.14.0.
@pizi-nordic FWIW the alternative timer infrastructure in my fork has no effect on the behavior of
referenced this issue
Apr 27, 2019
The diagnosis supporting #14991 is not correct. The error between the system clock (counting 10 ms ticks) and the cycle clock (counting 32 KiHz ticks) is not due to RC vs LFXT variation, but the fact that using
I've added #15707 which upstreams my patch to changes the default ticks-per-second on all Nordic platforms, and also restores the original fix for this problem.
I'm going to retract that: it's not so simple.
Here's instrumentation on the test that failed in #14186 when
Both of these taken from the branch used in #15707, with
I don't understand why this succeeds and fails the way it does, since in both cases the cycle timer---which should not be affected by the tick truncation---is used to measure the duration of the delay.
What I have observed is two things:
The result is that the first run after flashing with 100 t/s almost always fails, while subsequent runs after a reset usually pass. The first run after flashing with 128 t/s usually succeeds, and subsequent runs after a reset almost always succeed.
So there's just something really weird about the way the timing infrastructure works.
I missed this error source... The fact that on some board test passed and on others not as well as measurement results fixated my mind. Thank you @pabigot for pointing this out!