2 Replies Latest reply on Mar 30, 2014 10:46 PM by joki_2146851

    Maximum time spent in fineTimer callback


      I have setup the fine timer (in the context of the heart rate monitor application) to write a command byte to SPIFY2 and then read back 4 bytes.  This seems to work accept for the fact that the added time do the SPIFY2 work seems to add enough delay such that the heartrate monitor values don't get updated at the central (or at best get updated randomly every 10 to 100 seconds). Question is does the blocking of the SPI transfer cause a problem with the stack sending the updated heartrate value? (i.e. if there is a time slot that the Stack needs the updated value and if it is missed then it does not get sent (send over the radio)?). How do I get around this?

        • 1. Re: Maximum time spent in fineTimer callback

          The application can enqueue data/notification packets for transmission at any time and the stack will put it in the transmit queue. At every connection event, the packet at the head of the transmit queue will be sent out and if there are more packets in the queue, the current TX packet will have the MD bit set in the packet header to indicate to the peer device that there is more data and will send it out in the next frame (so the 20732 can send out multiple packets every connection interval). This is all in a higher priority interrupt context, so the blocking calls in SPI will not matter (unless you are locking out interrupts; the SPI driver does not lock interrupts during a transaction).


          What is the fine timer interval? If you trace out the data received over SPI instead of sending it over the air, do you see the right data at the correct intervals?

          • 2. Re: Maximum time spent in fineTimer callback

            The timer gets called and I see spi transactions on the oscilloscope. If I write fewer bytes there is no issue which is why I was worried about blocking behavior or too much time spent in the fine timer interrupt. I'm doing a write of 1 byte and a read of 4 bytes. I know I read elsewhere that SPI is blocking, but that might have referred to user available thread space. However if it was not blocking then the clock would be screwed up for the slave devices without variable length clocking capability. The fine timer fires every 100 ms, so spending 20us-50us in the timer seems like it should be ok not to cause this odd behavior.