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

SPI slave

This application uses a Rigado nRF52840 module to collect SPI data from 2 peripherals in slave mode.  I have been unable to get the SPIS example running in the target board using the SDK 15.0 example with minimal changes (I added a couple of lines to handle controls for the board and changed the SPI pin out).  Running this code seems to configure the SPI peripheral correctly and I have verified that the bus master in transmitting data but the '840 is not storing any in the RX buffer.  The SPI connections have been verified by pulsing the lines under '840 control and also with the SPI master running the bus.  I have commented out the BSP function calls since this is a custom board and I have not ported that code yet.  Pin assignments were passed in using the CMSIS configuration tool but are included in the sample below as definitions (I verified the correct pin numbers were passed in).  Based on this testing there seems to be a configuration problem preventing the input data (or some other line) from reaching the SPI peripheral and capturing data.

Any suggestions on where to look?

Here is the modified Main from the SPIS example (my changes are highlighted):

#include "sdk_config.h"
#include "nrf_drv_spis.h"
#include "nrf_gpio.h"
#include "boards.h"
#include "app_error.h"
#include <string.h>

#include "nrf_log.h"
#include "nrf_log_ctrl.h"
#include "nrf_log_default_backends.h"

#define SPIS_INSTANCE 1 /**< SPIS instance index. */
static const nrf_drv_spis_t spis = NRF_DRV_SPIS_INSTANCE(SPIS_INSTANCE);/**< SPIS instance. */

#define TEST_STRING "Nordic"
#define NUM_SAMPLES_PER_FRAME 800
static uint8_t m_tx_buf[NUM_SAMPLES_PER_FRAME]; /**< TX buffer. */
static uint8_t m_rx_buf[NUM_SAMPLES_PER_FRAME+1]; /**< RX buffer. */
static const uint16_t m_length = sizeof(m_tx_buf); /**< Transfer length. */

static volatile bool spis_xfer_done; /**< Flag used to indicate that SPIS instance completed the transfer. */

/**
* @brief SPIS user event handler.
*
* @param event
*/
void spis_event_handler(nrf_drv_spis_event_t event)
{
if (event.evt_type == NRF_DRV_SPIS_XFER_DONE)
{
spis_xfer_done = true;
NRF_LOG_INFO(" Transfer completed. Received: %s",(uint32_t)m_rx_buf);
}
}

#define START_PIN (uint32_t) 3
#define SPI_SCK_PIN (uint32_t) 11
#define SPI_CSNX_PIN (uint32_t) 12
#define SPI_MOSI_0_PIN (uint32_t) 13
#define SPI_MOSI_1_PIN (uint32_t) 14
#define SPI_MISO_0_PIN (uint32_t) 15
#define SPI_MISO_1_PIN (uint32_t) 16

int main(void)
{
// Enable the constant latency sub power mode to minimize the time it takes
// for the SPIS peripheral to become active after the CSN line is asserted
// (when the CPU is in sleep mode).
NRF_POWER->TASKS_CONSTLAT = 1;

nrf_gpio_cfg_output(START_PIN);
nrf_gpio_pin_clear(START_PIN); //stop data collection


// bsp_board_init(BSP_INIT_LEDS);

APP_ERROR_CHECK(NRF_LOG_INIT(NULL));
NRF_LOG_DEFAULT_BACKENDS_INIT();

NRF_LOG_INFO("SPIS example");

nrf_drv_spis_config_t spis_config = NRF_DRV_SPIS_DEFAULT_CONFIG;
spis_config.csn_pin = APP_SPIS_CS_PIN;
spis_config.miso_pin = APP_SPIS_MISO_PIN;
spis_config.mosi_pin = APP_SPIS_MOSI_PIN;
spis_config.sck_pin = APP_SPIS_SCK_PIN;

APP_ERROR_CHECK(nrf_drv_spis_init(&spis, &spis_config, spis_event_handler));

while (1)
{
memset(m_rx_buf, 0, m_length);
spis_xfer_done = false;

APP_ERROR_CHECK(nrf_drv_spis_buffers_set(&spis, m_tx_buf, m_length, m_rx_buf, m_length));

//start sampling
nrf_gpio_pin_set(START_PIN); //start data collection

while (!spis_xfer_done)
{
__WFE();
}
nrf_gpio_pin_clear(START_PIN); //stop data collection

NRF_LOG_FLUSH();

// bsp_board_led_invert(BSP_BOARD_LED_0);
}
}

Parents
  • I have resolved this issue and it was a data problem.  I assumed that the incoming data could not be all '0' and this led me to assume I was not receiving data.  The data was from an ADC but switching to a logic signal at the MOSI pin (one synchronized to the SPIS clock) allowed me to verify that the SPIS peripheral was working correctly.  Now to figure out why the ADC is acting like that... :-)

Reply
  • I have resolved this issue and it was a data problem.  I assumed that the incoming data could not be all '0' and this led me to assume I was not receiving data.  The data was from an ADC but switching to a logic signal at the MOSI pin (one synchronized to the SPIS clock) allowed me to verify that the SPIS peripheral was working correctly.  Now to figure out why the ADC is acting like that... :-)

Children
No Data
Related