How can I identify IRQ handlers that occur during a normal CPU execution?

[havingnordicfun]

I have a time-sensitive block of code run purely by the CPU, not within any interrupt handler or peripheral. Part of the execution is getting interrupted, and so what I would like is to simply identify which IRQ or IRQs are occurring, preferably in real time. To be clear, I am not looking for advice regarding superior techniques for time-sensitive operations, I would just like to identify which IRQ or IRQs are occurring in a particular block of code. Is there a way to do this in general, or is it a process of narrowing down the potential suspects. Detailed answers much appreciated. I am using Segger Embedded Studio in my development. Thank you!

[Edvin]

Hello,

You can set some breakpoints in your interrupts to see which one that triggered. There is no way from the main context (where I suspect you are running your time-sensitive block of code from) to know what interrupt that occured. 

Do you use BLE?

If the interrupt is a softdevice interrput, things are a bit more tricky. You can use some CRITICAL_REGION_ENTER() and CRITICAL_REGION_EXIT() to block these from happening. However, please be aware that this will block the softdevice completely. If the softdevice misses a time critical event, it may assert and reset your application. 

If you are using the softdevice and need to perform very time sensitive blocks of code, where you don't get interrupted by the softdevice, you either need to shut down all softdevice activity (disconnect and stop scanning/advertising), or you can use the Timeslot API, where you can request timeslots in between the softdevice events where you know that you will not be interrupted by the softdevice within this timeslot. 

To be clear, I am not looking for advice regarding superior techniques for time-sensitive operations

 Loud and clear. However, I don't know what sort of time sensitive blocks of code you are running. Could they be automated by timers and the PPI?

Best regards,

Edvin

[havingnordicfun]

Hi Edvin. This operation happens close to the beginning of main context (and yes, within the main context), and it's possible to do this before turning on the softdevice. I read in another thread that running __disable_irq() has no guarantee of stopping the softdevice, that it may take back control at any time. Why is that the case? Should I expect similar constraints with CRITICAL_REGION_ENTER? I'm fine with breaking softdevice functionality temporarily, but want to ensure it will not take back any control.

[Edvin]

If it is before you start using the softdevice, then it will not interrupt you. I thought this was something that you were doing on a regular basis. If it is only one time before you start using the BLE, then you should be fine. In fact, if you do it before you enable any other interrupts, then I guess there is nothing that will be able to interrupt you. 

Have you tried implementing this? Are you running into any issues with interruptions?

[havingnordicfun]

It has been implemented, and something is interrupting, I suspect it could be GPIO/GPIOTE. Do those peripherals trigger/enable the softdevice?

As background, I am ingesting a non-stop stream of ~175kb coming in from an external piece of hardware at >3Mhz that I need to write to memory. I opened up a private ticket regarding this a few months ago (Case ID: 238735, if you can view it). The behavior is that some of the 175kb are missed.

[havingnordicfun]

So to be clear, would CRITICAL_REGION_ENTER be guaranteed to disable all interrupts, even ones from the soft device? Why wouldn't __disable_irq() do the job, based on the thread I mentioned (https://devzone.nordicsemi.com/f/nordic-q-a/7321/how-to-enable-and-disable-all-interrupts)

Is the soft device on a separate piece of hardware that asserts its own control, or based on something else?

[Edvin]

havingnordicfun said:

would CRITICAL_REGION_ENTER be guaranteed to disable all interrupts,

 I would think so. I haven't seen any occurances of that not being the case. It is what it is designed to do. 

The Softdevice is a piece of software. Unless you have enabled it it will not do anything. 

 

havingnordicfun said:

I suspect it could be GPIO/GPIOTE. Do those peripherals trigger/enable the softdevice?

 No. Only if you have set up an interrupt to that GPIOTE, nothing will interrupt on those GPIOs. If you have set something up, that event will trigger. If that event handler actively call a softdevice function, that would activate the softdevice. If you haven't done that, then the softdevice shouldn't disturb you, unless you have started advertising or scanning, or you are in a BLE connection. 

Perhaps you can tell me what peripheral you are using to transfer this chunk of data? This peripheral will probably interrupt you, but I assume you are aware of that. You will e.g. get an interrupt every time you get an UART byte if you are using UART (unless you read in blocking mode, but then you may not have time to process the data before the next byte comes). 

A bit more background could maybe shed some light on what's going on, how you expect it to work, and possibly some issues. 

[Edvin]

I see you are using SPI. Perhaps you can show me some snippets of how you are reading out this data?

[havingnordicfun]

We've since abandoned SPI, the buffer size was too small to store our stream of data and we had no way to advance the EasyDMA ArrayList pointer by the amount we needed when we needed to. It was a few months ago, I can try to dig some of it up in old versions of our code. Additionally, the external hardware we're working doesn't support single channel SPI. We would need to use two SPI peripherals, which would be hairy, or Quad-SPI, which I'm not sure is supported by our external hardware either.