APP irq priority

[abe]

Hi, I have developed a BLE/ZigBee application starting from nRF5 SDK for Thread and Zigbee v3.2.0.
Now I need to add a "timer" for measurement timing most precise as possible.
I tried:
- RTC, but unfortunatly: RTC0 is locked by SoftDevice, RTC2 is locked by 802.15.4 radio functions and RTC1 is used by APP timers.
- configuring by application_timers_start() function an application timer.
In this last case, I tried to change the IRQ priority reconfiguring APP_TIMER_CONFIG_IRQ_PRIORITY macro inside sdk_config.h header file
As on comment here below, I tried with priority level 2 or 3, but as sonn as the BLE connect, the FW goes into Hard Fault Handler
Where I wrong?
In addition, using the application timer with IRQ priority level 6, irq timing is not granted: for example, using 1 millisecond timer, very often the timer is served after 3-5 milliseconds, but the very troublesome think is that the followings IRQ after this issue, starts very time shifted and the long time sincronicity is not longer granted
How can I solve this issue?
Abele

[ovrebekk]

Hi Abele

Would it be an option to use a TIMER module rather than an RTC module?

The nRF52840 has 5 TIMER modules available, so there is usually one or more available. 

Please note that running a TIMER module in sleep could increase sleep current, but if you're already running BLE and ZigBee this might not be noticeable on overall system current. 

Best regards
Torbjørn

[abe]

Hi  Ovrebeek,

TIMER modules use system clock, I think less stable of external 32768 clock crystal.
Really, my issue is that, when my device is disconnected from BLE, I need to handle and increment one local Unix Time Stamp variable (to use it as "RealTimeClock" ).
UnixTime Stamp variable will be used as clock when BLE is disconnected, and must grant the local time, with best precisione possible, for at least some week.
Any suggests are welcome how to solve this function
Many thanks

Abele

[ovrebekk]

Hi Abele

Do you really need millisecond accuracy for this?

If all you need is a local timestamp wouldn't second accuracy suffice?

I think using app_timer would be fine as long as you don't need to schedule callbacks at such a high frequency. 

Best regards
Torbjørn

[abe]

Hi Torbjørn

Yes, it's not needed a millisecond resolution, I think the best resolution could be 0,1 second.
My questions:
- for your knoledge, for some week or one month the clock time accuracy is enough?
- TIMER modules can take all IRQ priority levels or there are some limitation?
BR
Abele

[ovrebekk]

Hi Abele

abe said:

- for your knoledge, for some week or one month the clock time accuracy is enough?

This depends on the accuracy of the 32kHz crystal on your board. 

As an example, if you have a 20ppm crystal you will have a worst case drift of 1.7 seconds pr day:

(60*60*24) * 20 / 1000000 = 1.7

After a month this would add up to almost a minute. 

In other words you need to pick the crystal accordingly, in order to get the required level of accuracy. 

Please remember to read the crystal specifications carefully, in order to verify whether or not the quoted accuracy also takes temperature and aging factors into account. All crystals will be somewhat affected by temperature and aging. 

If you use a TIMER module for the time tracking then it is the accuracy of the 32MHz crystal that is relevant, and you need to make sure that this crystal is running at all times. 

By default it will only be enabled when the radio is needed. 

abe said:

- TIMER modules can take all IRQ priority levels or there are some limitation?

Whenever the SoftDevice is running it will occupy IRQ priorities 0, 1, 4 and 5. 

The IRQ priorities left for the application is 2, 3, 6 and 7. 

Best regards
Torbjørn

[abe]

Hello Torbjørn,

I'm bit confused... in one previous comment you said

ovrebekk said:

Would it be an option to use a TIMER module rather than an RTC module?

because on nRF5 SDK for Thread and Zigbee v3.2.0. there are no RTC available, then you suggested to use a TIMER module instead of RTC.

In addition, in my starting post I said

abe said:

I tried with priority level 2 or 3, but as sonn as the BLE connect, the FW goes into Hard Fault Handler

Your 32768 Khz clock precision considerations are right, but in my case RTC is not usable.

Abele