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]

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?