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

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

Einar Thorsrud — Wed, 17 Nov 2021 07:55:13 GMT

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.

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

venkatesha kj — Wed, 17 Nov 2021 04:23:47 GMT

file name is app error check

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

Einar Thorsrud — Tue, 16 Nov 2021 13:19:04 GMT

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).