JN5169 - Global Interrupt Masking

[mferrari1]

Using JN-SW-4163 (the IEEE 802.15.4 SDK for JN516x) with the JN5169, is there any provision for global interrupt masking?

I know that interrupts from individual entities can be masked individually, but is there a way to simply mask all interrupts temporarily? For example when reading or writing a semaphore flag and needing to make sure there is not a simultaneous access attempt by an interrupting entity.

Thanks,

Matt

[mferrari1]

Thanks Mario!

[mario_castaneda · Accepted solution]

Hi Matt,

Please look at the B.2 Peripheral Interrupt Sources (u32ItemBitmap). 

The bitmask indicates the individual interrupt source within the peripheral (except for the UARTs)

JN516x Integrated Peripherals API User Guide

Also, you could check the Interrupt system, The JN516x provides several interrupt sources, some associated with CPU operations (CPU exceptions) and others which are used by hardware in the device.

7 Interrupt System

Regards,

Mario

[mferrari1]

Hi Mario -

I have two more Interrupt related questions for the JN5169:

1) I am attempting to use the function vAHI_InterruptSetPriority(), but it appears that this function is unknown to the SDK.  When I include this call in my code I get the following warning:

 warning: implicit declaration of function 'vAHI_InterruptSetPriority' [-Wimplicit-function-declaration]

Is there an include file or path that's needed in order to use this function?

2) Regarding the global masking of interrupts, I found the following:

#define MICRO_DISABLE_INTERRUPTS(); \

asm volatile ("b.di;" : : );

#define MICRO_ENABLE_INTERRUPTS(); \

asm volatile ("b.ei;" : : );

Can these two macros be used successfully on the JN5169 to globally enable/disable interrupts?

Thanks Mario,

Matt

[mario_castaneda]

Hi Matt, 

If you are using multiple peripherals look at the irq_JN516x.S, You could set the priority for the modules and the system controller.

Makefile changes

##############################################################################
# Application Source files
ifeq ($(JENNIC_CHIP_FAMILY),JN516x)
APPSRC = irq_JN516x.S
endif‍‍‍‍‍‍‍‍‍‍

Hope it helps

Mario

[mferrari1]

Hi Mario –

I found that when I included the MicroSpecific_ba.h file, vAHI_InterruptSetPriority() compiled in just fine, without adding the “irq_JN516x.S” file to the Makefile, so please disregard my questions #1 & #2 below.

I am still curious if a lower priority IRQ that happens when a higher priority ISR is in process will pend and vector to its ISR once the higher priority ISR exits or not. Please clarify on this point.

Thanks Mario,

Matt

[mario_castaneda]

Hi Matt,

The interrupt with higher priority will be finished first and after that will give time for the next priority with a lower priority

Regards,

Mario

[mferrari1]

Hi Mario –

I’m sorry, I don’t understand your answer. Do you mean:

A) That while servicing a higher priority interrupt, a lower priority interrupt will be held as pending until the ISR from the higher priority interrupt exits and then the ISR for the lower priority interrupt that was pending will immediately be executed, or

B) That while servicing a higher priority interrupt, if a lower priority interrupt happens it will not be held as pending, and therefore its ISR will not immediately execute upon exit from the higher priority interrupt’s ISR, BUT that once the higher priority interrupt’s ISR does exit, then interrupts from lower priority interrupts can be detected and serviced?

In scenario (A), lower priority interrupts that happen while the MCU is servicing a higher priority interrupt will still be detected and the lower priority interrupt will still get serviced after the higher priority ISR is done.

In scenario (B), lower priority interrupts that happen while the MCU is servicing a higher priority interrupt are not detected, and thus their ISRs do not run upon exit from the higher priority interrupt’s ISR.

These two scenarios are distinctly different - please indicate which one of these is correct, or if neither is correct, then please clarify.

Thanks Mario,

Matt

[mario_castaneda]

Hi Matt,

A)     That while servicing a higher priority interrupt, a lower priority interrupts will be held as pending until the ISR from the higher priority interrupt exits and then the ISR for the lower priority interrupt that was pending will immediately be executed.

The MCU won't get out from the interrupt of high priority, the lower priority will be executed after the MCU exist from the high priority.

Regards,

Mario

[mferrari1]

Hi Mario –

Thank you for this information. It has prompted a few questions:

1) This file “irq_JN516x.S” - is there documentation for it, or its usage, anywhere? If vAHI_InterruptSetPriority() requires this file in order to work, there must be some reference to it somewhere? Also, in which directory of the SDK is this file located? I cannot find it anywhere.

2) User Guide JN-UG-3087 v1.5, Page-153 documents the function vAHI_InterruptSetPriority(). It says I need the Include File “MicroSpecific.h”. I have found this file, located at:

C:\NXP\bstudio_nxp\sdk\JN-SW-4163\Components\MicroSpecific\Include\MicroSpecific.h

But it appears that the correct file I should be using with the JN5169 is actually MicroSpecific_ba.h. There are a variety of files in this folder and they contain lots of definitions – I want to be sure I’m using the correct one. Can you please confirm if MicroSpecific_ba.h (not MicroSpecific.h as indicated in the User Guide) is indeed the correct file to use with the JN5169?

3) JN5169 Product Data Sheet Rev 1.3 (Page 25 of 95) states the following:

If while processing an interrupt, a new event occurs at the same or lower priority level, a

new external interrupt will not be triggered. However, if a new higher priority event occurs,

the external interrupt will again be asserted, interrupting the current interrupt service

routine. Once the interrupt service routine is complete, lower priority events can be serviced.

So if I get an Interrupt from DIO16 and enter the ISR, then while I’m in the ISR, if DIO17 then asserts an interrupt I will not see the DIO17 Interrupt while I am still in the ISR. But when I exit the ISR (entered because of DIO16) will the Interrupt from DIO17 still be pending, resulting in entry to an ISR to service DIO17? Or is it the case that when I’m in an ISR servicing an IRQ from a DIO that any IRQs that may occur from other DIOs will just never be detected? From the statement above, it appears that this may be the case, but that is very surprising if it’s true. That means that once a DIO causes an Interrupt and enters the ISR, all Interrupts from other DIOs will be permanently lost with no indication that they ever happened until the ISR is exited. Can you please confirm if my interpretation is accurate. If so, DIO IRQs are bound to be missed quite often – this has serious system implications…

Thank you for your support Mario. I look forward to your answers to each of the 3 questions above.

I am nearing completion of this new product design and am eager to resolve these items.

Thanks again Mario,

Matt