• State Suggested Answer
  • Replies 18 replies
  • Answers 2 answers
  • Subscribers 75 subscribers
  • Views 3751 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 288657
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

APP_TIMER_V2 does not appear to generate timer interrupts

RMV

I am using SDK 17.1.0 with an nRF52832 design similar to the P10040.

I was previously using the original timer application and things were looking good.
I decided to upgrade to SDK 17.1.0 and am using the uart example under 'ble_peripherals' to boot strap my project.

Based on another project using SDK 17.1.0, I decided to move up to the newer version of the application timer.
I defined the symbols 'APP_TIMER_V2' and 'APP_TIMER_V2_RTC1_ENABLED' in the build.

My first question is:  I do not quite understand "why do I need to enable the RTC1"?  -- and when I try to build without using this symbol then I get a build error that there is no RTC instance defined in the build.

My next comment (based on observations) is that when I enable RTC1 then I notice that the processor enters the nrf_power_mgmt phase but never fires the timer handler that I expect to be triggered every 1 second. I have validated that
    a) the firmware has indeed called the 'app_timer_init()' function, 
    b) that this 1-second timer has been created as a 'repeat-mode' timer with a 1 second timeout with no errors, and
    c) that the timer has indeed been started.

I am sure that I am missing something here -- likely some kind of connection between the hardware RTC and the firmware handler but am still struggling to nail it down.

Cheers
RVM

  • 0 in reply to RMV

    Hello again, RMV

    Thank you for your extreme patience with this.

    RMV said:
    On a different, but related, note I want to understand what it means when the documentation says:
    "The RTC library does not directly start or stop the RTC but rather schedules a request to do so in the future".

    Could you pinpoint exactly where in the documentation you read this, so that I may take a look?
    The app timer definitively starts the RTC (if it is not already running), but perhaps this is referring to the case when the SoftDevice is present and enabled, in which the application looses all access to direct clock control, and may only 'request' clock operations through the SoftDevice API?

    RMV said:
    There was, however, one more thing that I had to take care of before I got this fully working and that had to do with a bug in the RTC clock driver in SDK v17.x.y, as documented here: here

    Aha - I see. I was not aware that you were using FreeRTOS + the watchdog module. I see that an update has been requested in the ticket, and that my colleague Susheel will be back in office next week. You can subscribe to the ticket in order to receive a notification whenever there is an update, if you would like.

    Best regards,
    Karl

  • 0
    Karl Ylvisaker said:
    Aha - I see. I was not aware that you were using FreeRTOS + the watchdog module. I see that an update has been requested in the ticket, and that my colleague Susheel will be back in office next week. You can subscribe to the ticket in order to receive a notification whenever there is an update, if you would like.

    Hi Karl,

    No, I am not using the FreeRTOS -- just provided the link to describe an almost identical problem situation that I am encountering.

    Cheers

    RVM

  • 0 in reply to RMV

    Hello again, RVM

    RMV said:
    No, I am not using the FreeRTOS -- just provided the link to describe an almost identical problem situation that I am encountering.

    Thank you for clarifying - this is very helpful for me to know.

    I will ask my colleague Susheel if there has been any progress in the issue, as you also have asked in the other ticket.

    Best regards,
    Karl

  • 0 in reply to Karl Ylvisaker

    FYI, I have noticed that when I reset the MCU (via the 5-pin SWD interface) and stop at the reset vector, the RUNSTATUS register in the WDT has the value '1' i.e. WDT is enabled. This does not match the product specification which states that this register should be '0' at reset.

    Later on this bit is tested (in the source files associated with NRF clock driver)  to determine the status of the WDT component, and since it returns a TRUE the run status of the LFCLOCK is set/assumed to be ON.

    I suspect this is what is causing my issues but I need to dig a bit further into this.

    I also vaguely recall another ticket refer to this same issue and simply comment out this fragment of code as a local workaround for that user's use case.

    RMV

  • 0 in reply to Karl Ylvisaker

    Hi Karl

    I really need to know ASAP whether or not this issue is going to be resolved, or there is some workaround outside of the SDK that I can use to get the LFCLK being recognized by the Applicatiion Timer?

    Also, any clues on the hardware anamoly I noted below, in my update from a few days ago?

Related
Terms of service