unexpected sd_app_evt_wait() returning

[Torsten Robitzki]

Hello,

I have a BLE application, running a GATT server on a nrf52832. The main loop, is basically an endless loop, starting with a call to `sd_app_evt_wait()`, then handling events provided by `sd_ble_evt_get()`. I toggle a debug pin at the beginning and the end of the main loops body.

When I connect with a BLE client to the GATT server, the debug pin starts to toggle very quickly, with a period of ~12.5µs. I use a counter to ignore the first 1000 runs through the main loop, after which I insert a break point. No call to `sd_ble_evt_get()` returns any event. Before hitting the breakpoint, I store NVIC->ISPR[0] in a variable. The value of this variable is 1, which indicates, that `sd_app_evt_wait()` returned doe to a pending radio interrupt.

How can I avoid, to have `sd_app_evt_wait()` returning, even when there is no event to handle? How can I further investigate what happens here? (Softdevice in use is S132 Version 6.1.0).

Thanks in advance,

Torsten

[Torsten Robitzki]

Hi Simon,

thank you for having a look into my issue. I've played a little with the static counter, that I use to have the break point a little bit later in time. I've used 50000, 50010 and 55000. `ISPR[0]` is always `0x400000` and `ISPR[1]` is always 0. This would map to `SWI2_EGU2_IRQn`. As far, as I can see, I'm using neither the SWI, nor the EGU peripheral.

I wonder if there is something wrong with the method, I'm using to track down the interrupt, I'm looking for. This is the head of the body of my main loop:

unset_pin( debug_pin );
            sd_app_evt_wait();
    set_pin( debug_pin );

    std::uint32_t pending0 = NVIC->ISPR[ 0 ];
    std::uint32_t pending1 = NVIC->ISPR[ 1 ];
    (void)pending0;
    (void)pending1;
    static int i = 55000;
    --i;
    if ( i == 0 )
        for ( volatile int f = 0; f != 100; ++ f )
            ;

I'm setting the breakpoint at the body of the for loop. As I see that my collected client is interacting with the GATT server, I'm pretty sure, that delaying the break point works.

kind regards,

Torsten