• State Suggested Answer
  • Replies 18 replies
  • Answers 2 answers
  • Subscribers 74 subscribers
  • Views 3761 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

Parents
  • 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

Reply Children
  • 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?

  • 0 in reply to RMV

    Hello again, RMV

    Thank you for your patience with this.

    RMV said:
    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.

    I have reached out to the nRF5 SDK developers about this, and checked up on the internal issue that my colleague Susheel submitted in the other ticket, but there unfortunately does not seem to exist an estimate for when this fix might make it into an SDK release.

    RMV said:
    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?

    I have discussed this with some colleagues and I think it comes down to that you will have to make sure that the LFCLK start task is triggered regardless of the WDT status.
    You could for example do this through the HAL layer directly:

    ...
        nrf_clock_task_trigger(NRF_CLOCK_TASK_LFCLKSTART);
...


    You can see the detailed explanation in this ticket.
    Try this, and let me know if it resolves the issue you are seeing.

    By the way, are you aware of the Errata 132 for the nRF52832? My colleague Håkon mentions its significance in the referenced ticket as well.

    Best regards,
    Karl

Related
Terms of service