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?
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.