Timer is not accurate with softDevice.

RE: Timer is not accurate with softDevice.

Krzysztof Loska — Fri, 13 Feb 2015 21:54:09 GMT

You are right. My previous comment was false (so I deleted it to not confuse people). I read the problem description too quick before leaving the work on Friday evening :)...

RE: Timer is not accurate with softDevice.

JohnBrown — Fri, 13 Feb 2015 16:31:02 GMT

I don't understand how that could work. How are you going to get 96(assuming a gpiote toggle task) first channel compares before you get one second channel compare?

RE: Timer is not accurate with softDevice.

Stefan Birnir Sverrisson — Fri, 13 Feb 2015 15:26:49 GMT

I suspect the root of this delay in clock is that the CPU is not available to process the TIMER2 interrupt. This is because the softdevice blocks the CPU up to 6 ms during a radio event. The thing you can do is to avoid using the CPU for the generation of the clock. Do that by using PPI channels instead. That way you connect the TIMER2 event directly with GPIOTE task. You can see how that is done in the gpiote_example in the nRF51 SDK.

You would have to use sd_* function to configure and set the PPI channels after you initialize the softdevice. You can see an example of that in the PWM library on Github, namely in the nrf_pwm.c file line 57

RE: Timer is not accurate with softDevice.

JohnBrown — Fri, 13 Feb 2015 08:53:16 GMT

Your comment does not help at all with understanding what you want to do. However, it seems to me that if you use a timer/counter to generate the clocks pulses by using a GPIO task linked to.timer compare events, you can probably also link the timer event(or another event from the same timer, i.e. another compare) to an increment task on another hardware counter timer, which would count up to 48 and then generate a compare event that would link to a task that stops the first timer. Not entirely sure if this would work, I'd try it if I didn't have work to do - it's exactly the sort of thing I find fascinating.

RE: Timer is not accurate with softDevice.

Kyu — Fri, 13 Feb 2015 00:34:43 GMT

Actually, It is not I2C, but it is similar to i2c. To be more specific SDA doesn't make signals according to the SCL.

So I should make accurate SCL pulse.

RE: Timer is not accurate with softDevice.

JohnBrown — Thu, 12 Feb 2015 14:08:10 GMT

Firstly, I believe: NRF_TIMER2->CC[0] = 100; should be: NRF_TIMER2->CC[0] = 99; as the counter counts from zero. Aside from that, I think that when the soft device is running, the timer interrupts may be delayed substantially, as the BLE stuff has to take priority. It is fairly easy to use events and tasks to generate rock-steady clock pulses(as the hardware handles everything), the only tricky thing will be how to stop at 48 pulses when the interrupts can get delayed by as much as your trace suggests. I notice you have referred to SCL in the code, so I assume this is being used in some capacity relating to I2C? If so, are you ignoring the SDA signal? Perhaps some better explanation of what you are trying to achieve will result in more useful answers.