https://devzone.nordicsemi.com/f/nordic-q-a/47851/nrf52832-spi-driver-issueHi: 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. Accordingen-USTelligent Community 13Thu, 30 May 2019 06:07:28 GMThttps://devzone.nordicsemi.com/thread/190018?ContentTypeID=1Thu, 30 May 2019 06:07:28 GMT137ad170-7792-4731-bb38-c0d22fbe4515:e59f3c07-fac6-4750-b95b-3e53958f4394bevis<p>Thank you very much!&nbsp;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.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/189816?ContentTypeID=1Wed, 29 May 2019 09:14:59 GMT137ad170-7792-4731-bb38-c0d22fbe4515:adf1fb9f-5e3a-469f-a7a9-a6d66afd9276haakonsh<p>Is the first TX byte a read command? If that&#39;s the case then the RX buffer will be filled with whatever the state of the rx pin is during the first byte.&nbsp;</p><div style="clear:both;"></div>