app timer frequency increasing

[nrbrook]

I'm building a firmware for nRF52 which is using app timer v2 with RTC1. After a while, app_timer starts running many times faster than normal, and I'm not sure why. Nothing seems to happen to trigger it. Here is RTC1 while operating normally:

And here when the timer is running too fast:

Perhaps there is some memory corruption or something...what controls the app_timer speed other than RTC configuration? The RTC counter is increasing at a faster rate, to the point where a 1s timer occurs very rapidly (probably a few ms).

The LFCLK state is:

i.e. RC source. So it appears RC oscillator is running fast...why would that be?

[Einar Thorsrud]

Hi Nick,

Looking at your RTC registers the PRESCALER has he same value in both, so the RTC will count with the same frequency. The CC register is different, but that is set by the app_timer library. Generally, the app_timer2 library is a high level library that uses the RTC, but just looking at RTC registers isolated does not necessarily help in understanding app_timer issues. Can you explain what you mean by the timer running faster than normal? Is it that app timers time out too quickly? Do you have several timers, and is it common for all? Can you upload code that reproduces the issue? Also, which SDK version do you use?

[nrbrook]

Hi, I added a bit more detail to my question. The RTC counter is increasing at a faster rate, which suggests the RC oscillator is oscillating at a faster rate. Therefore this applies to all app timers, yes I do have several. It would be very difficult to provide code to reproduce, it could be related to the custom board design, and there is a large amount of code. I'm using 17.0.2.

When this happens, I have enabled the softdevice, but Bluetooth is not active. I am regularly measuring the temperature (every 5s) via the softdevice, perhaps this could be causing it? Perhaps if the temperature read coincides with the LFCLK calibration?

My config:

#define NRF_SDH_CLOCK_LF_SRC 0
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#define NRF_SDH_CLOCK_LF_ACCURACY 1
#define CLOCK_CONFIG_LF_SRC 0

[Einar Thorsrud]

Hi,

nrbrook said:

Hi, I added a bit more detail to my question. The RTC counter is increasing at a faster rate, which suggests the RC oscillator is oscillating at a faster rate.

This seems odd, but we should check this properly. If the problem is with your clock, then it is completely unrelated to app_timer, though you with see app_timer issues as a symptom (and any other users of the LFCLK). You can use this code to output the clock so you can measure it.

nrbrook said:

When this happens, I have enabled the softdevice, but Bluetooth is not active. I am regularly measuring the temperature (every 5s) via the softdevice, perhaps this could be causing it? Perhaps if the temperature read coincides with the LFCLK calibration?

Is it possible to test a BLE connection in this state? If that works, then the issue is not with the LFCLK itself, as an accurate 32.768 kHz clock is needed to maintain a connection.

I think it is to early to speculate on a reason without knowing more about what is going on. It could be that you trigger an unknown SoftDevice bug but it seems strange. Which SoftDevice version (and SDK version) do you use?

[nrbrook]

It is hard to reproduce this issue on demand. However, I know the RTC counter increases at a much faster rate. If I pause the debugger, record the counter register value, resume for 2 seconds and pause again it has increased by e.g. 0x4804f7=144 seconds. Is this sufficient to deduce that the RC is oscillating too fast? I will try to reproduce with Bluetooth enabled but I've only just seen the issue occur again today for the first time since my last post and I've been testing continuously. I will keep it paused in the debugger today in case you have any suggestions for registers I could check.

[Einar Thorsrud]

Hi,

nrbrook said:

If I pause the debugger, record the counter register value, resume for 2 seconds and pause again it has increased by e.g. 0x4804f7=144 seconds. Is this sufficient to deduce that the RC is oscillating too fast?

No, that is not sufficient. The RTC will continue to count even if you pause the CPU with the debugger. So in this case it matches if you paused for 142 seconds then let it run for 2 seconds before pausing again. The proof of the pudding here would be if you could toggle a GPIO using PPI from an RTC using for instance the code I referred to in my previous post and check that with a logic analyzer of oscilloscope. That way we can easily see the actual LFCLK frequency.

[nrbrook]

Ok, I will try. I definitely didn't pause the debugger for 144 seconds though.

[nrbrook]

Here is my code:

NRF_RTC1->EVTEN     = (RTC_EVTENSET_TICK_Msk );

    // configure GPIOTE
    NRF_GPIOTE->CONFIG[0] = ( (GPIOTE_CONFIG_MODE_Task      << GPIOTE_CONFIG_MODE_Pos)
                              | (9                  << GPIOTE_CONFIG_PSEL_Pos)
                              | (GPIOTE_CONFIG_POLARITY_Toggle << GPIOTE_CONFIG_POLARITY_Pos) )
                            | (0 << GPIOTE_CONFIG_OUTINIT_Pos);

    // configure PPI
    NRF_PPI->CH[0].EEP    = (uint32_t)(&NRF_RTC1->EVENTS_TICK);
    NRF_PPI->CH[0].TEP    = (uint32_t)(&NRF_GPIOTE->TASKS_OUT[0]);
    NRF_PPI->CHENSET      = PPI_CHENCLR_CH0_Msk;
    NRF_RTC1->TASKS_START = 1;

However, I only see a low voltage waveform on pin 9, and the frequency isn't correct. Is this code correct? I just copied from your link and removed the timer related code. app_timer sets up the RTC before this code runs.