NRF52832 SPI Driver Issue

[bevis]

Hi:

When I recently debugged the SPI driver, I found that when I used nrf_drv_spi_transfer to read the SPI to receive the return value, the first byte was always 0xFF. Actually, starting from the second byte was the correct value I wanted. According to the information found on the internet, when SPI TX starts, there will be 0xFF value returned. But nrf_drv_spi_transfer is a read-write integration design, and I don't know how to compatible with this phenomenon.

For example, when I want a value of 0x112233, the SPI driver returns 0xFF112233 to me, or if I only need a byte to return a value of 0x02, it actually returns 0xFF02 to me.

This will definitely lead to memory overflow for a pointer parameter of byte length. How can I solve it? Thank you

my spi init code as follow:

ret_code_t err_code;
nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG;
spi_config.miso_pin = W25X_PIN_MISO;
spi_config.mosi_pin = W25X_PIN_MOSI;
spi_config.sck_pin = W25X_PIN_CLK;
spi_config.mode = NRF_DRV_SPI_MODE_0;
spi_config.frequency = NRF_DRV_SPI_FREQ_4M;
err_code = nrf_drv_spi_init(&w25x_spi, &spi_config, spi_event_handler, NULL);

[haakonsh]

Is the first TX byte a read command? If that's the case then the RX buffer will be filled with whatever the state of the rx pin is during the first byte. 

[bevis]

Thank you very much! After many days of repeated comparisons, the root cause of the problem was finally found. The SPI will have a return value of 0xFF immediately after the Tx data starts. If the SPI library function provided by MCU platform is read-write integration, read BUFF must be set to NULL at the beginning of TX, TX BUFF must be set to NULL at the time of need to read, if not for NULL, it will trigger the receiving of extra bytes and cause program errors. For example, I want 0x4016. If BUFF is not NULL when I write instructions, I will get 0xFF4016 when I read real instructions. Like STM32, there is a SPI interface that provides a single write byte or read a single byte at the bottom of the library function. All debugging does not find these details. Attention should be paid to some drivers that provide good secondary packaging.