SPI Master high speed behavior, gapless transmission

[Sam]

Hi, I have a few questions about the SPI master module. I'm using it for an application that basically needs to be gapless. After quite a bit of work, I've gotten it to work full speed at 4MHz with no gaps (outside of an ISR). However, I had to do a few...undocumented things. In particular, it was necessary for me to switch the order of clearing the EVENT_READY flag, reading RX, and writing TX. In the example code, the order is EVENT_READY, RX, then TX, but when I change it around in my code (mainly for TX to be earlier) I can achieve continuous, gapless SPI transmission at 4MHz.

From what I'm guessing from observed behavior, there is an undocumented requirement for TX to be buffered at least (about) 4 SPI clock cycles before it comes up on the queue (or 1us). My optimized code seems to need just 2-4 cycles to achieve that requirement (reliably while waiting for EVENT_READY), so I need that TX to come earlier. Can this program order be reliably supported? I haven't observed any unexpected behavior yet. I'm assuming there's someone familiar with the internal SPI state machine who could comment on whether or not this might be unreliable in some situations. Otherwise I'm going to have to set up a testbench and everything to determine if we'll be able to achieve our required performance with the 51822 in production.

I also read somewhere that 8MHz operation can be set, but isn't reliable. Is this because it's impossible to write a loop on the Cortex-M0 that'll feed data and check flags fast enough? Is this still true for newer revision chips? (I'm using a G0 device IIRC, but I'd imagine I'll have a newer device for production).

There's some weird short/long pulses in the logic analyzer capture below, but I suspect that's just clock phase mismatch between the analyzer / nRF51822. It's for most intents and purposes gapless.

[RK]

Order of RX and TX doesn't matter. Do whichever first you wish to do first, once you get the EVENT_READY there's a slot to write the TXD, that's what you need. As long as you do clear the event and read RXD as well, you're good - you won't get another event until you do those things.

8MHz is settable and is reliable if you could guarantee to feed the TX buffer at that speed. At 8MHz you have 16 CPU cycles per byte output, if you can guarantee in the worst case to read the event, get a byte, put it into TXD, clear the event, read RXD and increment your pointer all within 16 CPU cycles then 8MHz should work. With a really simple data buffer and some assembly I guess that's possible, but only just. Newer chips won't change that, not unless the processor frequency is increased. What would be better would be a DMA for SPI master, but there isn't one, not yet.

Where's the requirement for gapless transmission coming from? Most (all?) SPI slaves I've so far come across are fine with gaps. You'll have problems with gapless if you have anything else going on, an interrupt firing for a timer or particularly the softdevice which is going to interrupt you when it feels like it.

Oh and if that's a Saleae trace, try capturing at a higher sample rate, looks like you are missing occasional transitions. I can get my Saleae to capture 8MHz SPI bursts by running it at full sampling speed.

[Sam]

The 8MHz timings are holding across at least 20 words, but I'm not sure about production reliability (personally I think we'll just stick to 4MHz if the ordering issue is safe) Someone from Nordic commented that 8MHz was "unusable," was just wondering if this was still true for current versions of the chip: devzone.nordicsemi.com/.../