Radio Notifications become inverted

[Nikolaus Wittenstein]

If I have a high-priority interrupt (or a series of them) that runs long enough to completely mask a radio notification, then all further radio notifications appear inverted. Program architecture aside, is there any way I can definitely tell whether a notification is an ACTIVE or a nACTIVE? It's very troublesome when I get it wrong.

As an aside, is there any reason I can't have the radio notification run at priority 0? By definition it will never run at the same time as the lower stack, so it seems like I should be able to make it high priority. And by the same token, is there a reason I can't use priority 2? I can use priority 1, meaning I'm allowed to interrupt the upper stack—any reason I can't just use priority 2 as well?

Alternatively, is there any way I can make SWI1 take priority over ADC if both interrupts want to run?

Thanks!

[Øyvind Karlsen]

Hi,

Are you using the SDK implementation of radio notification? If you use SoftDevice calls as described in the newly updated tutorial on radio notification you have the option to have events occur before, after the radio event or both. If you have them configured to trigger on both, set a flag to keep tabs on which it is, since the ACTIVE event will always come before the nACTIVE event.

Since the SoftDevice needs to be able to interrupt the application it has reserved priorities 0 and 2.

You can always configure radio notifications at priority 1 and ADC at priority 3. Are you asking about how to give one preference over the other at the same priority level?

Best regards,

Øyvind

[Nikolaus Wittenstein]

Øyvind,

Thanks for your reply! I have both notifications enabled. The problem is that I have other high-priority interrupts, and sometimes the radio notification interrupt doesn't get serviced until a second interrupt has happened. When this occurs, the application effectively never gets the ACTIVE event before the nACTIVE event, and so every future radio notification is "incorrect" in that the application thinks the opposite thing is happening. Does that make sense?

So what I'd like is a definitive way to know, not guess, not toggle a state variable that I have, but to actually know whether this is an ACTIVE or an nACTIVE interrupt. Is this possible?

I'll split the interrupt priority stuff into a separate question to avoid confusion.

Thanks! -Nikolaus

[Øyvind Karlsen]

Unfortunately there's no proper way to distinguish between ACTIVE and nACTIVE. I understand that this can be frustrating, I am forwarding this internally to see if anything can be done.

In general the interrupt that is triggered first is the one that is handled first. If you have two equal priority interrupts firing at the same time, the one with the lowest ISR number will be handled first.

If a radio notification event does not get handled and another one gets triggered they should become nested, ie. you should get back to back ACTIVE and nACTIVE events (if you have blocking interrupts this could happen at any time from the actual radio event). Are you seeing anything to indicate that this nesting fails, possibly the nesting vector could become full and overflow.

The most reliable way I can think of is to have radio notifications trigger at a higher priority than the other tasks you want to do. If that is impossible in your application, you might be able to use the scheduler, which we have a tutorial for here.

Best regards,

Øyvind

[Nikolaus Wittenstein]

I don't think you can get both ACTIVE and nACTIVE events nested because they use the same interrupt, SWI1. The ble_radio_notification code looks like this:

void SWI1_IRQHandler(void)
{
    m_radio_active = !m_radio_active;
    if (m_evt_handler != NULL)
    {
        m_evt_handler(m_radio_active);
    }
}

If the interrupt doesn't get handled in time, the interrupt flag will just get set again while it's already set, which is why the interrupt doesn't run twice.

[Øyvind Karlsen]

I don't really have a better explanation than that this is how it is implemented, there's more info on the infocenter for nRF51 and nRF52. The nRF52 is using an M4F processor and has access to more priorities.