why delay is needed after SPI transfer ?is it because SPI busy was not checked in SPI transfer API?

[venkatesha kj]

void DEV_SPI_WriteByte(UBYTE value)
{
// HAL_SPI_Transmit(&hspi1, &value, 1, 1000);
APP_ERROR_CHECK( nrf_drv_spi_transfer(&spi, &value, 1, m_rx_buf, 1));
// nrf_delay_us(100);
nrf_delay_ms(1);
}

i am using the above function to transfer the data but if i remove the delay function the code is hanged at NRF_BREAK_POINT error why?

[Einar Thorsrud]

Hi,

I cannot see from this short snipped what you do after the delay, which I assume is what is relevant here. Have you done any debugging to see what happens? As you say a break point is hit, I assume an error check has detected an error. Can you test with a debug build to see which file name, like number and error code that was from? (See An introduction to error handling in nRF5 projects).

[venkatesha kj]

file name is app error check

[Einar Thorsrud]

Yes, but that is not the relevant part here. If you test a debug build (with DEBUG and DEBUG_NRF defined), you will see from the error handler in which file name and line number you got which error code. If you also enable logging you get this in the log.

For instance if you use a project based on a SDK Segger Embedded Studio project, select the Debug build configuration to automatically get more debug logging. Then run the test and check the log. You should see an error message similar to this:

<info> app_timer: RTC: initialized.
<error> app: ERROR 15 [NRF_ERROR_FORBIDDEN] at C:\Users\eith\SDK\nRF5_SDK_17.1.0_ddde560\examples\ble_peripheral\ble_app_hrs\main.c:974
PC at: 0x00034141
<error> app: End of error report

Here you see where the error occurred, and what it was. That gives you a good starting point for further investigations.