It cannot use SPI to control TI cc1101 properly.

RE: It cannot use SPI to control TI cc1101 properly.

Edvin — Tue, 18 Oct 2022 12:05:25 GMT

Ok, then that was the case. If you want to keep it in the bsp_event_handler, you need to make sure that the SPI has higher priority than the bsp_event_handler.

Look for SPI_DEFAULT_CONFIG_IRQ_PRIORITY and NRFX_SPI_DEFAULT_CONFIG_IRQ_PRIORITY in sdk_config.h and set them to a higher priority (smaller number). Please note that if you are using the SoftDevice (Bluetooth Low Energy stack), then you need to make sure that you don't use the priorities that are reserved for the SoftDevice. You can see what priorities that are reserved here:

https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/processor_avail_interrupt_latency/exception_mgmt_sd.html?cp=4_7_4_0_15_1

Best regards,

Edvin

RE: It cannot use SPI to control TI cc1101 properly.

Ted — Tue, 18 Oct 2022 10:22:53 GMT

Hi Edvin,

I put my SPI code in the call back function of bsp_event_handler(bsp_event_t event). I moved it to main loop, then it works fine.

Thank you very much.

Ted Wu

RE: It cannot use SPI to control TI cc1101 properly.

Edvin — Tue, 18 Oct 2022 09:05:26 GMT

Hello,

[quote user=""]

so my code is locked while checking spi_xfer_done.

[/quote]

So from where are you calling this? (the function that is calling nrf_drv_spi_transfer() and while (!spi_xfer_done))?

Are you calling it from your main() function, or from some interrupt? (GPIO change, button press, bluetooth event, other interrupt...)

Make sure that your spi_xfer_done variable is a volatile, wherever you declare it. E.g.:

volatile bool spi_xfer_done = false;

This is to make sure that optimization doesn't mess with it and assumes it knows it's value without actually checking whether it was changed externally.

Then, if it still doesn't work, I assume that it is because you are waiting for spi_xfer_done to be set to true from inside another interrupt with the same or higher priority, not allowing access to the SPI interrupt that is supposed to set spi_xfer_done to true. Is that the case? If so, what interrupt are you waiting in?

Best regards,

Edvin