This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Why does nRF51822 spi_master.c have timeout code?

The provided module spi_master.c has timeout code and error returns from spi_master_tx_rx(...)

Given that there are no external control signals to the SPI block, only a data input, it should be impossible for this hardware to timeout. I checked the current PAN V2.0 and there are no problems listed for the SPI section.

Please explain why there is timeout code.

My research:

In my application, I am not using PPI or interrupts with SPI.

In using the SPI hardware, I do indeed see timeout problems. My research seems to show that the problems are related to faster rather than slower SPI frequency (I see a problem if it is 2 MHz, but not if 250 KHz), and also seems to be related to the double buffer on the TX path.

If I send the first two bytes one immediately after the other (as shown on page 131 Ref Manual V1.1 (matches my silicon rev), or page 138 on Ref Manual V2.1) it times out on EVERY transfer at 2 MHz.

If I only TX another byte after the prior data has been completed, and the received byte read, it does not time out. While this works, it is much slower than what should be possible. My application is an AD7680 ADC, and I need to read 3 bytes, preferably at 2 MHz.

Please explain what is really going on.

  • Hi Philip

    The SPI driver in the SDK is quite old, and was written for a very early revision of the nRF51822 chip. Back then the SPI hardware was less reliable, and the time out mechanism was put in place in case of HW issues.

    You are correct that this is not really needed any more, as there are no known issues with the current SPI implementation.

    For an example of an SPI driver without any timeout code, please have a look at the attached example. It is quick enough to write and read data back to back at 2 MHz (though there are some microseconds of delay before and after a transaction).

    Best regards Torbjørn

    SPI master example.zip

  • There is a bug in this driver which causes problems when using it with two SPI modules simultaneously. The variable 'SPI' which is global should instead be local to each function which uses it. Otherwise a function could set the variable and be interrupted by a function which tries to use the other SPI peripheral, overwriting the variable and causing the wrong peripheral to be used.

Related