system clock problem on NRF52 boards

[pabigot]

I'm running a multi-sensor application on the pca20020 (Thingy:52), with a periodic display of data to UART. I've driven the display both in a loop with a k_sleep, and with a k_timer. In both cases, the display stops after eight and a half minutes. This happens to correspond to the 24-bit wraparound of a Nordic RTC running at 32 KiHz (8:32.000 = 512 s = 2^24 ticks) . Which is suspicious.

Display of the sensor data, driven by interrupts, continues.

May be related to #9904 and/or PR #10556.

[pabigot]

More information that may be relevant:

• An application that has just the periodic display code gets past 8:32 with no difficulties.
• In the failing application there are sensor triggers at 1 Hz, 7 Hz, and 10 Hz, all using work queues, all producing UART output, so there's a lot of interruption going on.
• Letting the application run I get periodic additional output (which displays system uptime as HH:MM:SS.mmm) that indicates the system clock is not advancing at a constant rate: I get output that's supposed to be every 10 s anywhere from a couple minutes to over an hour between each timestamp.

[aurel32]

I have been trying to get OpenThread working on an nRF52840 dongle in the last days (I actually have a few pending patches to submit for it), and I have encountered this issue. Basically the network stops working after some time, but a few things like USB, and shell keep running. The other hand a simple thread toggling a led like in the blinky sample also stops executing at the same time the network stops working.

I have first thought the problem was more or less random, but I have just checked the logs, and they always stop around 8:32:00.

I guess PR #11627 might be (at least partially) a workaround for the same issue.

[pabigot]

I don't think #11627 is due to the same issue, though there may be another clock issue that causes it (I'm not at all convinced k_busy_wait() being wildly inaccurate is isolated to Nordic hardware; that's just what I use). Before reporting I tried reverting that patch and there was no change. There's no direct evidence that the system clock is running at the wrong rate, just that it doesn't handle overflow of the underlying timer correctly.

(NB: Original report and comment edited to replace 8:32:00 with 8:32.000: the problem does not occur eight hours in, but eight minutes in.)

[aurel32]

Yes, in confirm that in my case, the problem happens in around 8 minutes, not 8 hours.

[aurel32]

In my case CONFIG_TICKLESS_KERNEL=n is enough to get the network working more than 8 minutes and 32 seconds. I have a board still answering to ping after more than 25 minutes.