NRF52 not reading third SPI byte

[David Andresky]

Hi 

I am trying to port an SPI driver from a project for the NRF51822 to an NRF52832 and running into a problem reading more than two bytes. We are using SPI0 (not SPIM0) connected to an external flash chip.

Below is an image capturing an example of the problem. Here I am transmitting a command byte 0x9F (lower left) and then clocking in three bytes (lower right) from the flash chip. I expect the flash chip to transmit 0x9D 0x60 0x15 and that is exactly what I see in the waveform. However, the NRF52 only reads the 0x9D and 0x60 (which are double buffered), but it drops the 0x15. This same driver code works fine across multiple projects built for the NRF51.

Are there any known errata or issues regarding operation of the SPI peripheral on the NRF52? The only thing I can find in the documentation is the instantiation table in section 8.4 of the product specification where it says that the SPI peripheral is deprecated. But the rest of the document suggests the SPI peripheral is still supported. Are we supposed to move to the SPIM peripheral?

[Susheel Nuguru]

You should still be able to use the SPI module. I am guessing/hoping that you are using latest SDK drivers to communicate to your SPI module on nRF52832.  We have not known any other issue apart from the extra clock issue already mentioned in the Errata and this one does not match your symptoms.

Try your communication using SDK15.2 nrfx_spi.c driver

[David Andresky]

Hi Susheel,

We have our own driver, and like I said, it works on the NRF51.

In section 48.1.3 of the product specification there are a couple paragraphs about the READY event and reading bytes B and C. It is difficult to interpret but on a whim I decided to add 15 nops before reading in the third byte and this fixed the issue. The 15 nops added another half clock cycle to the gap and now I can read the data. I have run tests reading thousands of bytes in 256 byte increments without failure.

[Susheel Nuguru]

Thanks for lettings us know about this. I do not understand why this fixes the issue. They should not have been needed if you are reading them on the condition of getting READY event.

Just for future reference, can you please give us the code snippet to have a little more insights about the driver state at the time you add these nops.