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

SPIM nrf_drv_spi_transfer() usage

Hi,

I'm trying to get SPI working with an accelerometer (LIS3DH). I'm currently trying to use the nrf_drv_spi_transfer() function. See code snippets below.

    // Initialize SPI
	nrf_drv_spi_config_t spiConfig = NRF_DRV_SPI_DEFAULT_CONFIG;
	spiConfig.ss_pin = ACCEL_CS_PIN;
	spiConfig.miso_pin = SPI_MISO_PIN;
	spiConfig.mosi_pin = SPI_MOSI_PIN;
	spiConfig.sck_pin = SPI_CLK_PIN;
	spiConfig.mode = NRF_DRV_SPI_MODE_3;
	spiConfig.bit_order = NRF_DRV_SPI_BIT_ORDER_MSB_FIRST;
	nrf_drv_spi_init(&spi, &spiConfig, spiEventHandler, NULL);

    void spiEventHandler(nrf_drv_spi_evt_t const *p_event, void *p_context)
    {
    	SEGGER_RTT_printf(0, "spiEventHandler: %d\n", spiReadData[0]);
    	spiReadData[0] = 0x00;
    }

    void getAccelData()
    {
    	spiCommandData[0] = 0x8F;
    	nrf_drv_spi_transfer(&spi, spiCommandData, 1, spiReadData, 1);
    }

When viewing the clock on an oscilloscope I see that there are only 8 clock pulses and it's sending the correct packet of TX info (0x8F). However, I don't see any further clock pulses for reading. Also, the data that I get in the spiReadData buffer becomes 0xFF when the event handler triggers.

If I set the length of the spiReadData to 2, then I see the correct 16 clock pulses and the second item in the buffer is the expected value.

Any advice? Am I using the function incorrectly? I'm assuming that a transfer of 1 length for TX means send the 8 bits in the TX buffer, and a read of 1 length means pulse an additional 8 clock pulses to read the data into the RX buffer.

Thanks.

Parents
  • I do notice that if I do:

    spiCommandData[] = {0x8F, 0x00};
    spiReadData[] = {0x00, 0x00};
    nrf_drv_spi_transfer(&spi, spiCommandData, 2, spiReadData, 2);
    

    I get the correct number of clock pulses and my read data is {0xFF, 0x33}. I'm guessing that the length parameter defines basically the number of clock pulses, and the read is happening at the same time as the transfer, so the first read is garbage because that's when the first 8 bits are sending over a command or a register index so SDO is just high...and then next 8 clock pulses are when the read data is actually being sent over.

Reply
  • I do notice that if I do:

    spiCommandData[] = {0x8F, 0x00};
    spiReadData[] = {0x00, 0x00};
    nrf_drv_spi_transfer(&spi, spiCommandData, 2, spiReadData, 2);
    

    I get the correct number of clock pulses and my read data is {0xFF, 0x33}. I'm guessing that the length parameter defines basically the number of clock pulses, and the read is happening at the same time as the transfer, so the first read is garbage because that's when the first 8 bits are sending over a command or a register index so SDO is just high...and then next 8 clock pulses are when the read data is actually being sent over.

Children
No Data
Related