Using SPI Master on nRF52

RE: Using SPI Master on nRF52

MartinBL — Thu, 17 Sep 2015 10:26:56 GMT

I'm glad it works. I answered your post in the other thread. Feel free to accept and close this thread if you don't have more questions related to this.

RE: Using SPI Master on nRF52

Papyrus — Wed, 16 Sep 2015 19:46:35 GMT

Hi Marin,

Thanks for your clarification here. I have tried the loopback example with my pin configuration, and that works. Thus, I have taken your advise and not used this example as a starting pont for communication with a slave, rather I am using spi_master_with_spi_slave. Unfortunately there are similar problems in that the processor consistently and persistently faults out. To keep things clean, I have posted a new question so this one does not become unruly and overcomplicated :)

devzone.nordicsemi.com/.../

Hopefully the post above is a better starting point to troubleshoot my project.

RE: Using SPI Master on nRF52

MartinBL — Wed, 16 Sep 2015 11:29:07 GMT

I agree with you that the "double definitions" are confusing. I have reported it to our SDK team.
As I'm sure you know MISO is Master Input/Slave Output meaning it is the slave that is driving the line. Hence, my suspicion is that your slave is not working or configured properly. The MISO pin on the nRF52 should be properly configured by the drivers. The waveform you see might be some sort of interference from the MOSI or CLK line.
I suspect that this is because there is a function call to check_buf_equal() inside the spi_master_x_event_handler(). This function is comparing the TX and RX buffers and if they are not the same the function will return an error condition. So, if you have not removed these two lines:

result = check_buf_equal(m_tx_data_spi, m_rx_data_spi, TX_RX_MSG_LENGTH); APP_ERROR_CHECK_BOOL(result);

and if you are not doing a loopback or a have slave device that returns exactly what it receives your application will stall in the app_error_handler() function. If you have already taken care of this it might be because you are trying to transmit too fast and the SPI module is busy. This is a quote from the nrf_drv_spi_transfer() documentation:

If an event handler was provided in nrf_drv_spi_init() call, this function returns immediately and the handler is called when the transfer is done.

In other words, if you are using an error handler like spi_master_x_event_handler() and you don't make sure that the SPI is not busy before you start another transmission then nrf_drv_spi_transfer() will return NRF_ERROR_BUSY.

EDIT: Here is a relevant thread: SPI Master Example on nRF52 DK consistently fails.