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

Issue seen with nRF52840 and SPI (Master) Receving Bytes

Hi everyone,

I am seeing an issue where the SPI (master) ignores the first byte of RX buff and begins storing the received bytes from RxBuff[1] instead of RxBuff[0]. In addition to ignoring the first RX byte, the first clock cycles for RxBuff[0] is missing as well (i.e., instead of having 1 TX + 4 RX clock cycles for the below code example, there are only 1 TX + 3 RX; verified on the oscilloscope). I was not using any SoftDevice and the only peripherals used were app timers, UART, and of course SPI.

Below is the code I used for initialization and transferring bytes via SPI:

   nrf_drv_spi_config_t spi_config; //= NRF_DRV_SPI_DEFAULT_CONFIG;
   spi_config.ss_pin    = SPI_SS_PIN;
   spi_config.miso_pin	= SPI_MISO_PIN;
   spi_config.mosi_pin	= SPI_MOSI_PIN;
   spi_config.sck_pin  	= SPI_SCK_PIN;
   spi_config.orc		= 0xFF;
   spi_config.frequency = NRF_DRV_SPI_FREQ_4M;
   spi_config.mode      = NRF_DRV_SPI_MODE_0;
   spi_config.bit_order = NRF_DRV_SPI_BIT_ORDER_MSB_FIRST;
   // set our SPI0 configuration
   APP_ERROR_CHECK(nrf_drv_spi_init(&SPI0, &spi_config, SpiEventHandler, NULL));

...

void SpiEventHandler(nrf_drv_spi_evt_t const *p_event, void *p_context)
{
    // do nothing for now...

    return;
}

...

uint8_t TxBuff[5];
uint8_t RxBuff[20];
nrf_drv_spi_transfer(&SPI0, TxBuff, 1, RxBuff, 4);

Thank you for your help!

  • Hi Jay,

    SPI protocol is full duplex, meaning it can transmitt and receive at the same time. You should not see (# TX + # RX) cycles, but MAX(# TX, # RX) cycles. Since you tell the driver you want to receive 4 bytes, you will see 4 cycles. The first cycle will be both transmitt and receive cycle.

    I'm not able to reproduce the other issue you describe, using you code and the SPI example in SDK 13.0.0. Which example and SDK version are you using?

    Best regards,

    Jørgen

  • Ah, that makes sense! Thank you for your answer. I am currently using the SDK 13 and the issue I described (which is not an issue after reading your answer) makes sense since the the MISO pin is set to pulldown. So, when I send via MOSI, I will always get 0x00 (i.e., making it look like first RX byte is 'ignored').

Related