BLE affects TIMER1/2 accuracy

RE: BLE affects TIMER1/2 accuracy

Tim — Mon, 23 May 2016 14:53:08 GMT

Thanks Aryan. You are correct. Unfortunately my app does not have access to the softdevice API. The Simblee designers have acknowledged the issue and will fix in a future release, hopefully by exposing the hfclk softdevice calls so my app, as you suggest, can call sd_clock_hfclk_request after calling SimbleeBLE.begin(). Many thanks for your help with this Aryan.

RE: BLE affects TIMER1/2 accuracy

Susheel Nuguru — Fri, 20 May 2016 07:20:34 GMT

RTC does not use HFCLK, it only works on LFCLK.

The softdevice keeps and internal counter for requests and release of HFCLK. So you have to request the HFCLK through softdevice API for it to know that the app explicitly requested HFCLK XTAL. Otherwise it will turn it on and off as per own usage.

When you change the LFCLK to XTAL before begin(), it does not matter as the begin function will change it anyways (if it is not using XTAL).
Seems like your application before calling SimbleeBLE.begin(); has started Xtal HFCLK. This means that the softdevice have no idea about this and will assume that after enabling it no one else apart from it is using Xtal HFCLK. You have to change you code little bit here.

. first enable softdevice
. request hfclk xtal using softdevice api sd_clock_hfclk_request. If you do not have access directly to softdevice API then ask the team who has to expose that API to you. . Now configure your Timer

What we will achieve here is to let softdevice know that you are a user of the xtal hfclk. and Keep it on after it has finished its calibration. I would expect this to work for you.

RE: BLE affects TIMER1/2 accuracy

Tim — Thu, 19 May 2016 22:23:08 GMT

Thanks Aryan. The call to SimbleeBLE.begin() starts the softdevice. Unfortunately I don't have access to that code. Before calling SimbleeBLE.begin(), I change the LFCLK source to Xtal and no difference in behaviour. I did notice something interesting though. When I check the NRF_CLOCK->HFCLKSTAT register before calling SimbleeBLE.begin(), I get the value 0x00010001, which, according to the Nordic nRF51822 v3 reference manual, means the HFCLK source is Xtal (16 MHz HFCLK crystal). After calling SimbleeBLE.begin(), the NRF_CLOCK->HFCLKSTAT register changes to 0x00010000, which means the HFCLK source is now RC (16 MHz RC oscillator). Unlike LFCLK, I don't see a task for setting the HFCLK source. Regardless, though, I presume I can't change it once the softdevice has started. Also interesting, if I repeat the above test using RTC1 instead of TIMER1, RTC1 values are accurate. Thoughts? Thx!

RE: BLE affects TIMER1/2 accuracy

Susheel Nuguru — Thu, 19 May 2016 06:41:20 GMT

You said that the capture value is always 31589 ±3 when you start BLE, this is very interesting. What LFCLK clock are you using when you enable the softdevice? is it RC LFCLK with regular calibration? If so, the calibration of RC clock starts crystal HFCLK until the calibration is done. This could affect the accuracy of the TIMER because of the switch happening many times during these two seconds?

RE: BLE affects TIMER1/2 accuracy

Tim — Wed, 18 May 2016 05:57:35 GMT

Thanks RK. I think I share your understanding. I realize that interrupt routine calls can be delayed due to softdevice priority. As I see it, my code does use PPI (simblee_ppi_channel_assign), along with GPIOTE, to start and stop the timer according to the function generator's 1 second pulse. Before my interrupt routine is called, PPI has already stopped the timer, so no matter what the delay is into the interrupt routine, the timer value should reflect the duration of the 1 second pulse. The interrupt routine then clears the timer to get ready for the next pulse. This code is just for investigation purposes. You give me hope that using TIMER, PPI and GPIOTE, I can get a stable, accurate timer. Thx.

RE: BLE affects TIMER1/2 accuracy

RK — Wed, 18 May 2016 03:12:46 GMT

oh note you can probably get the cycle more to the correct length by using the SHORT between COMPARE and CLEAR instead of clearing in your IRQ handler - however the result of that will just be to get the average period about right, but increase the amount of variability your IRQ handler gets called with.

RE: BLE affects TIMER1/2 accuracy

RK — Wed, 18 May 2016 02:35:34 GMT

Yes - do a search - this is discussed many times a week.

The softdevice has a higher interrupt priority than anything else, it has to have, it has critical timing requirements. So your interrupt can get delayed by up to several milliseconds, the more the bluetooth stack does, the more you get delayed. All the timings are in the softdevice specification. Once you're in a connection shoving data around, your delays are going to get only larger.

You cannot do interrupt-based precise timings with the softdevice in use, it doesn't work. You need to use PPI or the PWM module which Nordic provides which uses PPI to work independently of the softdevice.