Read continuous stream of data over SPI

RE: Read continuous stream of data over SPI

Arsalan Chauhdary — Fri, 20 Feb 2026 11:56:33 GMT

Hi,

From the stack trace and behavior you’re describing, this looks like a classic race condition between two SPI transactions occurring at different interrupt contexts. Even though both are configured at priority 6, an interrupt can still preempt execution depending on timing and how the driver state flag (transfer_in_progress) is being read and updated.

The issue likely isn’t that NRF_ERROR_BUSY isn’t implemented — it’s that the second call may be entering before the first call has safely set the flag in a thread-safe manner. Since the driver isn’t fully protected against simultaneous access across contexts, this can corrupt the state machine and cause the READY event loop to stall.

A safer approach would be:

Implement an external mutex or atomic lock around nrf_drv_spi_transfer().
Use CRITICAL_REGION_ENTER() / CRITICAL_REGION_EXIT() when checking and updating your own SPI-busy flag.
Ensure both SPI calls execute from the same execution context (either both main loop or both ISR-driven but serialized).

Disabling RTC interrupts during active chip select is possible, but architecturally it’s cleaner to serialize access instead of masking interrupts.

In complex embedded systems — much like scalable backend systems we design at halo digital, a leading web development company USA — shared resources must always be guarded externally if the driver itself isn’t fully thread-safe.

The key here is controlled access, not retry loops.

Hope this helps clarify the root cause.

RE: Read continuous stream of data over SPI

nordev — Sat, 20 Feb 2021 16:55:14 GMT

As an update, this is clearly here for a reason, as it creates a bunch of garbage data when I remove the "handler" condition. None of my SPI transfers actually result in correct data if this condition is gone (see the commented out part), though I can't figure out why.

I was able to use the app scheduler successfully though. Thank you for your help!

RE: Read continuous stream of data over SPI

Einar Thorsrud — Thu, 18 Feb 2021 09:45:36 GMT

Hi,

Sorry, I always think in terms of non-blocking calls so I forgot again that you were using blocking. As long as you use blocking API calls that is correct, it will not be a problem. In most real products where you do not want to waste CPU time and power you will use non-blocking calls, but you are right that it should be OK to ignore this issue in your specific use case.

RE: Read continuous stream of data over SPI

nordev — Thu, 18 Feb 2021 09:14:47 GMT

Thanks so much for your help.

Just to sanity check, but I was thinking about it again, and if the transfer_in_progress flag were set properly, it seems like I wouldn't actually run into the problem you describe here?

[quote userid="7377" url="~/f/nordic-q-a/71336/read-continuous-stream-of-data-over-spi/294958#294958"]the main loop may start a SPI transaction and the transfer_in_progress flag may be read, but before it is written to a RTC interrupt occurs.[/quote]

because if the main loop starts an SPI transaction, but doesn't get to setting the transfer_in_progress flag before it gets interrupted, won't the interrupt return and let the main loop keep going only after it is done with its SPI transfer? And if the SPI transfer that was initiated by the main loop didn't even get to sending the transfer_in_progress flag, that means it hasn't actually started sending anything yet, so there wouldn't be two conflicting uses of the same resources? So the flow would be, main loop calls the SPI driver --> gets interrupted before setting flag --> second transfer gets started --> second transfer completes and returns to main loop SPI driver call --> first transfer starts and completes. Unless I am misunderstanding how the interrupts work, please let me know.

I was getting the issue only because the flag wasn't being set, so the first SPI transfer was actually in the middle of sending data when the interrupt happened.

RE: Read continuous stream of data over SPI

Einar Thorsrud — Thu, 18 Feb 2021 08:23:43 GMT

Hi,

[quote user="nordev"]1) Is there any way to define some sort of generic function prototype that I can make a queue for? [/quote]

I would suggest the app_scheduler here. That is designed for exactly this use case. It is essentially just a queue that you put stuff into when handling interrupts, and process in the main loop. You will queue a function pointer and a context data (so it can be anything, you decide - and as large as you want as long as you adjust the element size for it). There are no good examples in the SDK, but the usage is quite simple so you can refer to examples\nfc\writable_ndef_msg\main.c. Essentially you first initialize the queue so that it holds the largest elements you need. Then you queue stuff using app_sched_event_put() when handlign the interrupt, and process it in your main loop by calling app_sched_execute().

[quote user="nordev"]2) Do you know a way I can do this? [/quote]

You can disable the interrupt any time and then re-enable it. If an interrupt is pending it will be processed. I do not know if you use the RTC driver, but if you do interrupts are enabled when you init it. You can do this directly using NVIC_EnableIRQ(RTC1_IRQn) and NVIC_DisableIRQ(RTC1_IRQn) - adjust if using other RTC instance.

If you ask me option 1 is by far the best. That is a straightforward and sensible way of handling this and similar issues, and is how you would typically solve this in a complex application.

RE: Read continuous stream of data over SPI

nordev — Thu, 18 Feb 2021 07:58:08 GMT

EDIT: I realized it is rather unwieldy to add all of the things that might call SPI to the main loop, especially since there is stuff I haven't implemented yet that I will have to add in the future, and maybe there will be even more beyond that. I decided that the best solution would be to add SPI callback functions to a queue that then gets processed in the main loop, if this is possible. My problem is that all my callback functions will have different parameters . 1) Is there any way to define some sort of generic function prototype that I can make a queue for?

Alternatively, I discovered this note:

which suggests that "interrupt pending" flags are set independently of interrupts being enabled or disabled. Which suggests that I can disable interrupts, then incoming interrupts will set "interrupt pending" flags but not execute, and then whatever has an interrupt pending flag will simply execute once I re-enable interrupts. This is what I was getting at here:

[quote userid="85290" url="~/f/nordic-q-a/71336/read-continuous-stream-of-data-over-spi/293883#293883"]what I would like is for RTC interrupts to be disabled while a transfer is in progress (i.e. while chip select is low) and re-enabled when the transfer completes (chip select goes high), such that any interrupt that tries to happen in the middle of a transfer instead happens immediately after the transfer completes.[/quote]

2) Do you know a way I can do this?

As a final alternative.... if I remove p_cb->handler and use the NRF_BUSY return code to try again if a transfer was in progress, it would be probably very rare for something to interrupt after the transfer starts but before the "transfer in progress" flag gets set, right? So I could accept this risk, and maybe would have to reboot the device once in a rare while, if it is sufficiently rare (like 1 in 100,000 attempted SPI transfers). 3) Or maybe do you have some suggestion for making this flag-setting atomic?

Thank you for your help!

RE: Read continuous stream of data over SPI

nordev — Wed, 17 Feb 2021 20:50:33 GMT

Thank you.

Will you consider asking the development team to remove the p_cb->handler condition from the driver in a future SDK version?

RE: Read continuous stream of data over SPI

Einar Thorsrud — Wed, 17 Feb 2021 19:05:23 GMT

Hi,

[quote user="nordev"]right now, the only conflicting things that might simultaneously call the SPI driver are my main loop (not interrupt based) and the RTC interrupt. Given that I don’t expect anything else to be able to interrupt my RTC interrupt, I should be safe, right? [/quote]

I am not sure about that. If you make calls to the driver from both your main loop and an RTC interrupt, that means you may have this problem (think of the main context as the lowest possible priority). Specifically, the main loop may start a SPI transaction and the transfer_in_progress flag may be read, but before it is written to a RTC interrupt occurs. Then the a new transaction might be started from the RTC interrupt.

[quote user="nordev"]I think this interrupt comes from the softdevice, which means there’s nothing I can do about matching interrupt priority, correct? So I have to make sure they don’t conflict in some other way. [/quote]

Yes, that will have SoftDevice priority. You could move execution down to the main loop for all SPI transactions, perhaps. Either using some synchronization flags or using the app_scheduler or another mechanism. That is one way to avoid having to think about this. Alternatively, you can use a mutex as mentioned before, and handle this yourself outside the driver. Which is more appropriate depends on the specific application, but both are common approaches.

RE: Read continuous stream of data over SPI

nordev — Wed, 17 Feb 2021 15:10:38 GMT

[quote userid="7377" url="~/f/nordic-q-a/71336/read-continuous-stream-of-data-over-spi/294826#294826"]There is nothing preventing transfer_in_progress from being checked first, then an interrup toccuring checking it again, and then writing it. [/quote][quote userid="7377" url="~/f/nordic-q-a/71336/read-continuous-stream-of-data-over-spi/294128#294128"]then it is theoretically possible that the second call with higher priority would interrupt the first after the transfer_in_progress was read but before it is written to. And then you would have problems[/quote]

so this could still be a potential problem.

right now, the only conflicting things that might simultaneously call the SPI driver are my main loop (not interrupt based) and the RTC interrupt. Given that I don’t expect anything else to be able to interrupt my RTC interrupt, I should be safe, right?

eventually though, I will add another SPI transfer that will be triggered from a Current Time Service interrupt. I think this interrupt comes from the softdevice, which means there’s nothing I can do about matching interrupt priority, correct? So I have to make sure they don’t conflict in some other way.

RE: Read continuous stream of data over SPI

Einar Thorsrud — Wed, 17 Feb 2021 11:58:32 GMT

Hi,

That is good spotted

[quote user="nordev"]1) Did nordic intend this behavior? (basically, did I do something wrong, or is this a bug?)[/quote]

I am not sure if this is intended or not. You could argue that when using blocking mode it is easy for you to ensure that there is no conflict. And you would only be able to get a problem here if calls are made from different interrupt priorities. If that happens and they can overlap in time, then this will not be enough. On the other hand, there is no atomic operations or critical sections for updating the transfer_in_progress flag in any case, so you would still risk issues if calling from different interrupt priorities and not ensuring that one transaction finish before you initiate the next.

[quote user="nordev"]2) Do you see any issue with me removing p_cb->handler from the conditional above in (2.)? [/quote]

No, I do not immediately see any issues. But note my point above. There is nothing preventing transfer_in_progress from being checked first, then an interrup toccuring checking it again, and then writing it. So the driver is not thread safe and if you call the API from different interrupt priorities you must ensure that there are no collisions outside of the driver. Alternatively, ensure that you always call the driver API from the same interrupt priority, then this is no issue.

RE: Read continuous stream of data over SPI

nordev — Tue, 16 Feb 2021 23:23:48 GMT

Hi Einar,

As an update, I found out what the issue is:

I hope this image is big enough for you to see, but basically:

1. there is only one place in the driver where transfer_in_progress() is ever set to true

2. it is guarded by the following conditional:

if (p_cb->handler && !(flags & (NRF_DRV_SPI_FLAG_REPEATED_XFER |
                                        NRF_DRV_SPI_FLAG_NO_XFER_EVT_HANDLER)))
        {
			p_cb->transfer_in_progress = true;
        }

3. flags are 0, which is not a problem, but handler is ALSO 0, which is a problem. So the condition is never satisfied, and even though there is a transfer in progress, the transfer_in_progress boolean is always false.

Handler = 0 because I initialize the SPI driver with:

err_code = nrf_drv_spi_init(&m_spi_at, &config, NULL, NULL);

Because I thought I don't need a handler if I am not using interrupts, since I am in blocking mode.

My questions:

1) Did nordic intend this behavior? (basically, did I do something wrong, or is this a bug?)

2) Do you see any issue with me removing p_cb->handler from the conditional above in (2.)?

RE: Read continuous stream of data over SPI

nordev — Tue, 16 Feb 2021 22:35:39 GMT

[quote userid="7377" url="~/f/nordic-q-a/71336/read-continuous-stream-of-data-over-spi/294128#294128"]So a new transaction would not be able to cause problems for an old, but should just result in the second call failing with NRF_ERROR_BUSY.[/quote]

I don't know if this is actually the case, and I think the following concern still stands:

[quote userid="7377" url="~/f/nordic-q-a/71336/read-continuous-stream-of-data-over-spi/294128#294128"]So sure I might get an error code, but the damage will already have been done: the second transfer will have already disrupted the first transfer, which is what gets me stuck in the infinite while loop. [/quote]

Because I changed my code in this function (code in a previous response):

[quote userid="85290" url="~/f/nordic-q-a/71336/read-continuous-stream-of-data-over-spi/293630#293630"]at_read_status_once()[/quote]

to do this:

while(nrf_drv_spi_transfer(&m_spi_at, spi_tx_cmd, sizeof(spi_tx_cmd), spi_rx_buf, sizeof(spi_rx_buf)) == NRF_ERROR_BUSY);

so that if I got a NRF_ERROR_BUSY event it would just try again until it isn't busy. But I still get stuck in this while loop forever inside spi_xfer():

Here is the full stack. I have highlighted the two calls to nrf_drv_spi_transfer().

The first one is called from my main loop, and the second one is called from an RTC interrupt. My RTC is also a low interrupt priority, 6.

Note that NRF_ERROR_BUSY should be returned from nrf_drv_spi_xfer (second in the call stack above). But this does not happen -- "p_cb->transfer_in_progress" seems to be false, even though there IS a transfer in progress (first highlight on above stack):

What do you think is happening? Is this a bug with SDK 14.2? Is it fixed in later versions?

-----

As a separate matter, I had to refresh this webpage 5 times to get the "reply" button to show up at the bottom of your latest message (it showed up at the top underneath my original message but not elsewhere). Generally, every time I use the forum, I have to refresh multiple times in order for the reply button to show up. Perhaps you can relay this to your web development team.

RE: Read continuous stream of data over SPI

Einar Thorsrud — Fri, 12 Feb 2021 10:52:45 GMT

Hi,

[quote user="nordev"]is the right way to do this APP_ERROR_CHECK()?[/quote]

No. APP_ERROR_CHECK() is used to catch unexpected errors. The default error handler in the SDK will log and break if an error is detected with this and in debug mode. If in release mode it will perform a soft reset - in order to recover from an unexpected and unhandled error. The correct is to handle any expected errors specifically, and then call APP_ERROR_CHECK() if the return value was not an expected/handled error, like you suggest with "if(nrf_drv_spi_transfer() != NRF_ERROR_BUSY)".

[quote user="nordev"]So sure I might get an error code, but the damage will already have been done: the second transfer will have already disrupted the first transfer, which is what gets me stuck in the infinite while loop. [/quote]

This stems from my incorrect previous answer, I guess. The driver checks if a transaction is ongoing before doing any changes. So a new transaction would not be able to cause problems for an old, but should just result in the second call failing with NRF_ERROR_BUSY. There is a slight possibility for an issue here though, as this is not implemented in thread safe way. So if the two calls are made at the same time with different priorities then it is theoretically possible that the second call with higher priority would interrupt the first after the transfer_in_progress was read but before it is written to. And then you would have problems. This would be solved by always calling from the same priority, or by using a proper check externally (using a mutex of similar).

[quote user="nordev"]is there some way to check without actually calling the SPI transfer function to see if it generates an error?[/quote]

There is no API for that in the driver.

To sum up, if you call from the same priority, you can just rely on handling the NRF_ERROR_BUSY. If not, you should implement your one mutex on the outside. So that one "user" will lock the driver before starting and operation and unlock it when finished. And the same with the second. You could use nrf_atomic_u32_t for that, or just a volatile variable that you read and update in a critical region (CRITICAL_REGION_ENTER() / CRITICAL_REGION_EXIT()).

[quote user="nordev"]are there other benefits of bundling the BLE event handling like this besides being able to queue interrupts & not lose them?[/quote]

There are no extraordinary benefits in the context of BLE events or even nRF5 SDK specifically. It boils down to general concepts of handling interrupts / priorities. If you have a need to move processing of events/interrupts (BLE or other) down from interrupt context to main context, then using the scheduler makes sense. If not, then there is no need. Typically the more complex an application is and the more different interrupts etc or the longer the interrupt routines, the more important it becomes to move priorities down. That way stuff that can wait may wait, and there is time to process other interrupts in in a timely manner. But there is no right or wrong way here, it is application dependent. This is related to the general importance of keeping ISRs short. If you want to do a lot of work because of an interrupt, but only a small portion of it is time critical you can do the small portion in the ISR, and then queue the rest in the scheduler to be processed in the main context.

RE: Read continuous stream of data over SPI

nordev — Fri, 12 Feb 2021 05:01:18 GMT

Thank you Einar.

[quote userid="7377" url="~/f/nordic-q-a/71336/read-continuous-stream-of-data-over-spi/293904#293904"]You should get NRF_ERROR_BUSY if attempting to start a second transaction before the first has finished.[/quote]

is the right way to do this APP_ERROR_CHECK()?

The strange thing about checking this way, however, is that I have to actually call nrf_drv_spi_transfer() in order to get the error code. Either with APP_ERROR_CHECK() or something like “if(nrf_drv_spi_transfer() != NRF_ERROR_BUSY)”.

So sure I might get an error code, but the damage will already have been done: the second transfer will have already disrupted the first transfer, which is what gets me stuck in the infinite while loop.

is there some way to check without actually calling the SPI transfer function to see if it generates an error?

[quote userid="7377" url="~/f/nordic-q-a/71336/read-continuous-stream-of-data-over-spi/293904#293904"]Do you call app_sched_execute() from your code? [/quote]

no, I do not. are there other benefits of bundling the BLE event handling like this besides being able to queue interrupts & not lose them?

RE: Read continuous stream of data over SPI

Einar Thorsrud — Thu, 11 Feb 2021 08:36:34 GMT

Hi,

First of all, I was a bit surprised when I checked the driver implementation yesterday and did not find a check for not starting a second transaction before the first finished. I turns out I glanced over it too quickly, though. You should get NRF_ERROR_BUSY if attempting to start a second transaction before the first has finished. So that means you can use this. Sorry for the confusion.

Regarding chip select / slave select it is correct that the SPI peripheral does not handle that. However, the driver implements support for chip select by controlling a GPIO. So when you use the driver you get it handled for you.

[quote user="nordev"]How do I know if I am using the scheduler?[/quote]

Do you call app_sched_execute() from your code? If yes, you are using the scheduler, if not you are not using it. If you also set NRF_SDH_DISPATCH_MODEL to 1 in your sdk_config.h BLE events are using the scheduler (meaning put in the queue and processed when you call app_sched_execute()). As you are not aware of it I suspect you are not using it.

Regarding the rest of the section about interrupts it is actually quite simple. To be specific:

Any interrupt will be processed immediately as long as it is enabled and no same or higher priority interrupt is currently being serviced.
- If an interrupt of same or higher priority is being services, the new interrupt will be serviced immediately after the previous is finished (assuming no other higher priority interrupt occurs in the meantime).
- A interrupt routine that is interrupted by a higher priority interrupt will continue once the higher priority interrupt routine has finished.

Now, there are SW concepts that can be used to make some things easier. The app_scheduler can be used to queue events from any interrupt priority. Then you process the queue in your main loop, so it is not in an interrupt (so basically lowest possible priority). That is useful sometimes, particularly in more complex applications.

Regarding SoftDevice that uses some peripherals that generate interrupts, but you will from the application only see SoftDevice interrupts that you are supposed to handle (in form of SoftDevice events). Interrupts from other peripherals (like for UART and RTC instances you are using) are forwarded to the application directly (it is actually done by the SoftDevice with slightly increases the interrupt latency, but other then that you can think of it as if the SoftDevice plays no role in it).

[quote user="nordev"]And interrupting another interrupt is ok, so long as the second interrupt is from a different source?[/quote]

If you get a lot of the same interrupts before you can process them with the same IRQ number (same source), that will cause you to lose interrupts. This is one of the reasons you should keep interrupts routines short. Other then that, interrupt from the same source cannot preempt another from the same source, as they will always have the same priority. But an interrupt with higher priority then one currently being serviced will interrupt that one.

RE: Read continuous stream of data over SPI

nordev — Thu, 11 Feb 2021 05:49:59 GMT

[quote userid="7377" url="~/f/nordic-q-a/71336/read-continuous-stream-of-data-over-spi/293744#293744"] it is your responsibility to wait for the first transaction to finish before starting the next[/quote]

Option 1:The RTC interrupt ultimately triggers the second transfer. Is there a way to temporarily disable the RTC interrupt, such that the event that should trigger the interrupt is registered (an interrupt flag is set, perhaps), but doesn't actually trigger the interrupt until after interrupts are enabled again? In case a RTC interrupt should happen in the middle of an existing SPI transfer, what I would like is for RTC interrupts to be disabled while a transfer is in progress (i.e. while chip select is low) and re-enabled when the transfer completes (chip select goes high), such that any interrupt that tries to happen in the middle of a transfer instead happens immediately after the transfer completes.

Option 2: Is there a way to check if the SPI resource in question is in use? I could place a condition on the SPI transfer called by the RTC interrupt callback so that it only executes if the SPI resource is free and waits otherwise. This would have the same effect as #1 and probably be more elegant.

Also, just to clarify, is this sentence from your link from an outdated specification? "The SPI master does not implement support for chip select directly." I ask because I see that spi_config() includes a way to designate the chip select pin, and the spi driver itself seems to perform operations with this designated pin -- in fact, I rely on the drivers and don't set/clear chip select directly. I am using SDK 14.2.

[quote userid="7377" url="~/f/nordic-q-a/71336/read-continuous-stream-of-data-over-spi/293744#293744"]If you use the app scheduler and schedule SoftDevice events, then those would be processed in the main loop, so any code executing in an interrupt would block it[/quote]

How do I know if I am using the scheduler? Above I mention two SPI transfers, one initiated by the RTC ("type 1"), and the other initiated by a request by the central to a BLE characteristic ("type 2"). Are you saying that the disconnection event doesn't get processed when it occurs in the middle of the type 2 SPI transfer because BLE disconnect constitutes a SoftDevice interrupt, and the type 2 SPI transfer is already operating in a SoftDevice interrupt? So it seems that you can't interrupt an interrupt with another interrupt of the same kind. But other events, like UART interrupts and the aforementioned RTC interrupt (even though it has a low interrupt priority of 6) are able to execute simply because they are NOT operating in a SoftDevice interrupt? So the SoftDevice doesn't handle things like UART or RTC? And interrupting another interrupt is ok, so long as the second interrupt is from a different source?

Thank you

RE: Read continuous stream of data over SPI

Einar Thorsrud — Wed, 10 Feb 2021 11:53:29 GMT

Hi,

[quote user="nordev"]1) Do you have suggestions for how to mitigate this problem?[/quote]

SPI is always full duplex. So whenever you transmit x bytes, you also receive x bytes. This is why you always need to provide both an Rx and Tx data buffer in the driver. But you cannot start two transfers at the same time, that will cause problems. Unfortunately the driver does not have a sanity check for this, so it is your responsibility to wait for the first transaction to finish before starting the next. Failing to do so will lead to problems so this should be fixed before anything else.

[quote user="nordev"] 2) Why do you think some interrupts are being generated, but others not?[/quote]

The typical reason for not getting some events is if the CPU is doing some work in the same or higher interrupt priority. I assume that is the case here? Regarding BLE the SoftDevice use two interrupt priorities (0 for mostly for internal usage and 4 for events to the application etc.) If you use the app scheduler and schedule SoftDevice events, then those would be processed in the main loop, so any code executing in an interrupt would block it (that is the case if using scheduler and having configured NRF_SDH_DISPATCH_MODEL to 1 in sdk_config.h).

[quote user="nordev"]3) Can you tell me the chain of events that causes the "READY" event to get generated?[/quote]

The short description is that the READY event every time a new byte is moved to the RXD register. For more details I suggest you refer to the SPI master transaction sequence section in the SPI chapter in the product specification.

RE: Read continuous stream of data over SPI

nordev — Tue, 09 Feb 2021 21:45:27 GMT

As an update, I found out when specifically this "stuck in loop" problem seems to occur:

I have an RTC that generates a COMPARE event every X seconds, upon which it calls my at_read_status_once() fn from above, which TX data to the peripheral. The "stuck in loop" problem happens if the SPI TX command happens while SPI RX is in progress from the same peripheral. The SPI TX and SPI RX were initiated with two separate nrf_drv_spi_transfer(). In theory, SPI is supposed to allow duplex communication, so the simultaneous RX and TX should not be a problem; the issue is probably that at_read_status_once() expects a RX response, but there is already a separate RX in progress. 1) Do you have suggestions for how to mitigate this problem?

Somehow, UART interrupts are able to get through, as you can see from the screenshot above, but other interrupts don't. For example, because the bluetooth device is caught in this while loop, it isn't sending connection packets to the central, and the connection fails -- but no interrupt is generated to process the tasks inside ble_event_handler() case BLE_GAP_EVT_DISCONNECTED. 2) Why do you think some interrupts are being generated, but others not? (note, RTC interrupt priority = 6. connection related events come from the softdevice, which i thought has the highest interrupt priority)

3) Can you tell me the chain of events that causes the "READY" event to get generated?

RE: Read continuous stream of data over SPI

nordev — Tue, 09 Feb 2021 18:48:10 GMT

[quote userid="7377" url="~/f/nordic-q-a/71336/read-continuous-stream-of-data-over-spi/293374#293374"]Where transfer_byte() is called from depends on if using the driver in blocking mode or interrupt driven. If blocking, it is called from spi_xfer()[/quote]

I am using blocking mode, and my call stack does include spi_xfer()

I decided to handle this by just polling for the status byte over and over and receiving 1B back each time, instead of modifying the SDK to read a continuous stream.

But I seem to be hitting an infinite loop because this READY event you mention doesn't get generated sometimes:

[quote userid="7377" url="~/f/nordic-q-a/71336/read-continuous-stream-of-data-over-spi/293374#293374"] In either case it is called when a READY event has occurred, which according to the product specification happens in this situation: "The SPI master will generate a READY event every time a new byte is moved to the RXD register.".[/quote]

Here is my call stack. The highlighted line is where it is stuck. It just so happens here that a separate interrupt happened, so other code executed for a moment.

My code is like this:

uint8_t at_read_status_once(void)
{
    uint8_t spi_tx_cmd[1] = {CMD_READ_STATUS_1};
    uint8_t spi_rx_buf[2];	// 1 B tx, 1 B rx

    nrf_drv_spi_transfer(&m_spi_at, spi_tx_cmd, sizeof(spi_tx_cmd), spi_rx_buf, sizeof(spi_rx_buf));
    return spi_rx_buf[1];	// 2nd byte is the rx response
}

And I call it like this:

while(at_read_status_once() != 0x0);

My purpose is to stay in the while loop and not move onto the next instruction until the status byte turns to 0x0. This works sometimes, but sometimes, this gets stuck in the while loop in the SDK here:

Why is the READY event never getting generated?

RE: Read continuous stream of data over SPI

Einar Thorsrud — Mon, 08 Feb 2021 14:53:07 GMT

Hi,

[quote user="nordev"]1. this still requires me to specify an RX buffer length, which I don't necessarily know in advance.[/quote]

Yes, that is the case. For the SPI peripheral that is not enforced by the HW (which just has double buffered Rx and Tx buffers), so you could write your own driver or modify the driver if that is a problem. Or perhaps simpler, just call nrfx_spi_abort() in the middle of a transfer if you find that you do not need to continue.

[quote user="nordev"]2. the below function also is dependent on transfer_byte(), but I am not really sure under what circumstances it is called.[/quote]

Where transfer_byte() is called from depends on if using the driver in blocking mode or interrupt driven. If blocking, it is called from spi_xfer(). If non-blocking (which is probably what you will use in most cases), it is called from irq_handler(). In either case it is called when a READY event has occurred, which according to the product specification happens in this situation: "The SPI master will generate a READY event every time a new byte is moved to the RXD register.".

[quote user="nordev"]Why does the end of spi_xfer() only set the chip select back high and not do the rest of the things in finish_transfer()?[/quote]

That is because it is a blocking function. So there is no callbck function to call etc.

[quote user="nordev"] If I choose to modify the functions, is there any downside to calling finish_transfer() after while (transfer_byte(p_spi, p_cb)); inside spi_xfer()? [/quote]

I am not sure why you want to do that? I think you first need to decide to use blocking or non blocking and also understand the driver if you want to make changes to it (other than hooking into transfer_byte() just to read as I suggested, as that does not change the driver behaviour in any way).

RE: Read continuous stream of data over SPI

nordev — Fri, 05 Feb 2021 18:32:52 GMT

Thank you Einar. One complication with using this method is that most of the time, I want to read a SPI buffer of known length, and only sometimes, I want to process each byte as it comes in in the manner described above.

I suppose I could create a duplicate transfer_byte() function, as well as a duplicate of all the functions that depend on transfer_byte(), such as spi_xfer(), nrf_drv_spi_xfer(), and nrf_drv_spi_transfer(), and simply call the modified functions (e.g., "my_nrf_drv_spi_transfer") when I need to. But two issues:

1. this still requires me to specify an RX buffer length, which I don't necessarily know in advance.

2. the below function also is dependent on transfer_byte(), but I am not really sure under what circumstances it is called. It seems somewhat redundant with the end of spi_xfer(), except that finish_transfer() is more thorough. Why does the end of spi_xfer() only set the chip select back high and not do the rest of the things in finish_transfer()? If I choose to modify the functions, is there any downside to calling finish_transfer() after while (transfer_byte(p_spi, p_cb)); inside spi_xfer()?

static void irq_handler_spi(NRF_SPI_Type * p_spi, spi_control_block_t * p_cb)
{
    ASSERT(p_cb->handler);

    nrf_spi_event_clear(p_spi, NRF_SPI_EVENT_READY);
    NRF_LOG_DEBUG("SPI: Event: NRF_SPI_EVENT_READY.");

    if (!transfer_byte(p_spi, p_cb))
    {
        finish_transfer(p_cb);
    }
}

Do you have recommendations for a way to approach the continuous stream read that do not encounter the issues above? Thank you!

RE: Read continuous stream of data over SPI

Einar Thorsrud — Fri, 05 Feb 2021 13:42:11 GMT

Hi,

There are several ways to do this and I am not sure which is better. Using the SPI (and not SPIM) peripheral you will use the CPU for every byte, and you can inspect it. The driver is designed to handle this for you though, but you could for instance do a small hack and add your own callback function that is called from within the transfer_byte() function in nrfx_spi.c so that you can process each byte as it comes in, but still let the driver do it's work as normal.