Problem with APP_TIMER

[Lars M]

Hi,

I run nRF5 SDK 15.3.0 with SES 4.30c on a PCA10040. Yesterday I upgraded to nRF5 SDK 17.0.2 and SES 5.60. When I connected PCA10040 I got a message that something wanted to be upgraded. I clicked Yes. Now when I run the debugger in SES I don't get interrupts om APP_TIMERs. When I turn off the debugger and run the board standalone, everything works fine.

I have three different PCA10040, and all behave the same. But I only got the message, that I mentioned above, once. I have tried to go back to 4.30c and 15.3.0, but the behaviour is the same. When I check the properties for the COM-port for each of the boards, all of them have notes that something around the UART has been upgraded. The driver is "JLink CDC UART Port (COMx)" from SEGGER, date 2019-06-06, version 1.34.0.44950. So the driver seems to be a couple of years old. But the notes still say that something has been upgraded.

I just connected my third board, and the first time I ran it I got interrupts on APP_TIMER when I ran the debuuger in SES. But when I restarted it, the interrupts stopped coming.

Do you have any idea of what might have happened? Can the boards have been upgraded in some way? Is it possible to go back to a previous version of some driver or firmware that is involved in this?

Best regards,
Lars

[Lars M]

Yes, it's definitely the same thing. I see that an internal bug report was to be created. But the problem is present in the latest SDK, and I can't see somewhere how to do a workaround. Or did I miss something? How should I handle it? Commenting the rows in the SDK feels completely wrong. Running 15.2.0 works fine. But using an older SDK also seems a not so good solution.

Should I just start lfclk "manually" by calling nrfx_clock_lfclk_start if it is not started by nrf_drv_clock_lfclk_request()?

[Kenneth]

Lars M said:

How should I handle it?

I suggest to follow the suggestion in my last link:
https://devzone.nordicsemi.com/f/nordic-q-a/63998/freertos-wdt-sdk17-problem/263131#263131

Hopefully this will be fixed in nRF5 SDKv17.1.0 that is supposed to be released in 1-2weeks.

In general you may find this useful:
https://devzone.nordicsemi.com/f/nordic-q-a/65422/what-are-sdk-17-x-0-known-issues/ 

Kenneth

[Lars M]

I'm sorry, I'm probably blind, but I can't see what the suggestion is. I only see a confirmation where the problem lies.

I have now added these two lines

if(!nrf_clock_lf_is_running())
    nrfx_clock_lfclk_start();

right after

nrf_drv_clock_lfclk_request(NULL);

where lfclk should have been started. It's not a pretty solution, but it works for now.

/Lars

[Kenneth]

That is a good a suggestion as any. The suggestion I linked was to comment out the following in nrf_drv_clock_init():

    if (nrf_wdt_started())
    {
        m_clock_cb.lfclk_on = true;
    }

[Lars M]

Aha! But I don't like to make adjustments to the SDK :-) Hope this will be solved to next release.

Thanks for your help!

/Lars