Is there a way to determine if an interrupt is currently nested? That is to say, while servicing the interrupt can I determine if there is another interrupt (of the same type) pending?
I'm using a BF537 with VDK
Thanks in advance.
For interrupt nesting to happen on Blackfin it is necessary for each interrupt service routine (ISR) to perform PUSH RETI shortly after entry and POP RETI shortly before returning from the ISR. Unless the contents of the RETI register are saved in this way the global interrupt disable (bit 4 in IPEND) will remain set (1) for the duration of the ISR and will prevent any other interrupts (even of higher-priority) from being serviced. This mechanism is provided by the hardware in order to protect the return address in RETI from being overwritten by a nested interrupt.
So in order to see if interrupt nesting is active, all you need to do is to check your ISRs if that contain the PUSH RETI/POP RETI code.
Thank you for your reply. I found similar details in the documentation and this makes sense to me if the ISR is written in assembly. The project I'm working on is using VDK and the ISR is written in C. Here, we've used the macro `EX_REENTRANT_HANDLER(EVT_IVG8_Entry)` to specify the ISR as reentrant. My understanding is that macro essentially pushes and pop RETI for me.
What I'm trying to determine is when a particular ISR is running is there another ISR that is interrupting or has been interrupted. Is there a way to determine this?
Furthermore, in the case where interrupts are reentrant, that happens to interrupts that are triggered by lower priority than a currently running ISR? Does the lower priority ISR wait until the higher priority one is finished or is the lower priority one lost?
At the moment, I am trying to troubleshoot a problem which appears to relate to using both the PPI bus and LwIP at the same time and I think there is a problem related to the interrupts servicing the PPI and LwIP. The interrupt servicing the PPI is set as reentrant. But I don't know how the LwIP interrupts are configured. It appears that LwIP is hanging at some point and if I halt the processor using an USB-ICE, processor seems to be stuck running its `VDL::IdleThread::Run() -> _adi_int_NestingISR()` function (according to the Call Stack window in VDSP).
Any further clarification you could provide would be appreciated.
Sorry for the delay in response. We understand that you have already contacted our private support. Please continue the discussion there to avoid the duplication of effort. We will post the final response here for others to benefit
can you please post the final response here, as stated in your answer?
I've recently resolved the issue that was causing this event. It turns out that sometimes my board was experiencing anomaly 05000489 - PLL May Latch Incorrect Values Coming Out of Reset. I believe that our board design correctly mitigates this anomaly with workaround #3 (however, we still appear to be hitting this problem) and so hadn't been looking at originally. When the anomaly is not hit, the board works fine, when it is hit, our clocks are not running at the speeds we thought they were and so we could not handle the interrupts as we expected.
We are still working with private support on mitigating the anomaly. Unfortunately, this does not really answer the original question I posed (or yours). But hopefully this background will help you or others in the future.
Retrieving data ...