• State Verified Answer
  • Locked Locked
  • Replies 11 replies
  • Subscribers 76 subscribers
  • Views 2608 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 276303
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

'POWER_CLOCK_IRQHandler' gets called after ~100seconds under unknown circumstances (causes the product to freeze)

Mircea Coman

Hi,

We have a product already on the market for about 2 years, based on nrf52840 and nrf52832. 

The product receives data from an 'external device' via UARTE, forwards the data to a washing machine via UARTE, get response from the machine, sends it back to the device. Repeat.

The device is using a reoccuring freertos timer started with app_timer_create and app_timer_start which updates a TIME variable via a callback. Timer is 'APP_TIMER_MODE_REPEATED'.

Recently we noticed some devices 'hanging' and I found the cause: POWER_CLOCK_IRQHandler' gets called after ~100seconds under, which stops updating the TIME variable via timer callback, and the firmware freezes as it needs time capability.

'nrf_clock_lf_is_running()' returns true and 'NRF_RTC1->COUNTER' is no more incremented.

It seems that if the 'external device' is in the mode which sends lots of data to our device, the bug is occuring. The bug is even occuring when I am not explicitly reading serial data from the external device.

If the device is set in a mode that sends data rarely, the bug does not seem to occur. Also the problem is not occuring if we disconnect the 'external device' to it.

Any ideas what might causing the disabling of the CLOCK interrupt?

Thank you.

  • 0 in reply to Mircea Coman

    What are the conditions under which CLOCK can be stopped intarnally? Is it even possible that the RTC counter is not incredemented anymore, timer callback not called and still, 'nrf_drv_clock_lfclk_is_running()' returns true ? 

  • 0 in reply to Mircea Coman
    Mircea Coman said:
    What are the conditions under which CLOCK can be stopped intarnally?

    That should never happen. The application should be in complete control of when the LFCLK is on or off. And most applications tend to keep it always on.

    Mircea Coman said:
    I tried running the code on an development board (instead of the production board) and 'POWER_CLOCK_IRQHandler' is called right at the beginning of device execution...

    Interesting.. So what clock source are you using on your board? Have you tried with a different source? E.g. sdk_config.h::CLOCK_CONFIG_LF_SRC 2 /*Synth */

  • 0 in reply to Vidar Berg

    Vidar, it worked! Changing Clock source to Synth caused the 'POWER_CLOCK_IRQHandler' to be always called right after device started and the CLOCK did not stop since (wirking as expected).

    What I also discovered is that if I enable the SoftDevice by default, the CLOCK also doesn't stop, even if I leave the Clock source to '1' in 'sdk_config.h'.

    Thank you!

  • +1 in reply to Mircea Coman

    Glad to hear that it worked. But please note that the Synthesized clock source is generally not recommend because it may increase the idle current (it forces the HF clock to always be on like UART does).

    I'm still not sure why the LFXO is behaving strangely. Have you changed load caps or the 32K crystal recently?

  • 0 in reply to Vidar Berg

    Is it possible that this condition could occur with the softdevice enabled (using HFCLK and external LFCLK)

Related
Terms of service