Radio Notifications become inverted

RE: Radio Notifications become inverted

Øyvind Karlsen — Mon, 27 Jun 2016 06:00:30 GMT

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.

RE: Radio Notifications become inverted

Nikolaus Wittenstein — Fri, 24 Jun 2016 13:11:04 GMT

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.

RE: Radio Notifications become inverted

Øyvind Karlsen — Fri, 24 Jun 2016 07:46:53 GMT

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

RE: Radio Notifications become inverted

Nikolaus Wittenstein — Thu, 23 Jun 2016 14:48:17 GMT

Ø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

RE: Radio Notifications become inverted

Øyvind Karlsen — Thu, 23 Jun 2016 14:01:15 GMT

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