Wake up sd_app_evt_wait() from application

RE: Wake up sd_app_evt_wait() from application

ves — Thu, 25 Mar 2021 18:16:49 GMT

I created a new ticket

devzone.nordicsemi.com/.../sd_app_evt_wait-behavior

RE: Wake up sd_app_evt_wait() from application

brianreinhold — Thu, 25 Mar 2021 17:52:55 GMT

Turns out everything that is happening wakes up that method. In my case it was a periodic timer. However, there is no information about what the event is that wakes up the method. I just get a number that isn't always the same.

RE: Wake up sd_app_evt_wait() from application

ves — Thu, 25 Mar 2021 16:21:15 GMT

I have a similar issue but on different product 52832/s132

Should i raise another ticket (different product) or we can continue the discussion here?

RE: Wake up sd_app_evt_wait() from application

Hung Bui — Tue, 09 Mar 2021 11:20:30 GMT

I see. We will try to improve our documentation.
If there isn't any further question. I would suggest to close the case.

RE: Wake up sd_app_evt_wait() from application

brianreinhold — Fri, 05 Mar 2021 11:16:17 GMT

Hung,

'Application event' is kind of vague. In fact, I have another thread posted asking just what is an application event? It may be obvious to the implementers of the SDK and SoftDevice but to outsiders, it's not quite so clear, I first thought it was an event I could also define (thus application event) and could use to wake an efficient sleep much like a semaphore. (I guess that's what I was hoping because I was looking for a way to emulate a semaphore.)

Believe me, I have looked at as much documentation as I could find on this method! Just wish there was some more. Well for my app at least it controls everything.

RE: Wake up sd_app_evt_wait() from application

Hung Bui — Fri, 05 Mar 2021 10:38:43 GMT

Hi Brian,
If you read the description of the function sd_app_evt_wait() you get what the function is about:

/**@brief Waits for an application event.
*
* An application event is either an application interrupt or a pended interrupt when the interrupt
* is disabled.

The app_timer (which is not part of the softdevice) is an application library and the interrupt it uses is RTC interrupt which is an application event. Any application event will wake up the chip from sd_app_evt_wait(). What don't wake up the chip from sd_app_evt_wait() is BLE activities that the softdevice can handle on it own without involving the CPU/application.

RE: Wake up sd_app_evt_wait() from application

brianreinhold — Thu, 04 Mar 2021 13:40:02 GMT

Okay, that explains it. I have an app timer that is repeating fairly quickly. I understand that would wake up the CPU, but that does not mean sd_app_evt_wait() gets signaled. I did not know the app timer was part of SoftDevice; figured it was part of the RTC and had its own firmware. But okay, there is more that triggers sd_app_evt_wait() than I originally thought. Maybe more info in the docs about it? Perhaps most do not do what I am doing and handle sd_app_evt-wait() but use the SDK.

RE: Wake up sd_app_evt_wait() from application

Hung Bui — Thu, 04 Mar 2021 11:06:23 GMT

Hi Brian,

[quote user="brianreinhold"] if I have a timer with a hundredth of a second interval and I start any timer (or just create that timer) that sd_app_evt_wait() will be woken up 100 times a second (at minimum)?[/quote]

I assume we are talking about app_timer here (the library), not the TIMER hardware or the RTC timer hardware. If you have a recurring app_timer of 1/100s then yes, it will wake the CPU up every 1/100s to handle the timer timeout. Without the CPU how can you handle an interrupt ?
By functionality I meant timer, or any CPU activity that you create in your application. If you have nothing but just initialize softdevice, enable BLE (no advertising) and a loop of sd_app_evt_wait() then the CPU shouldn't wake up at all ( except for LFCLK calibration if you use RC).

RE: Wake up sd_app_evt_wait() from application

brianreinhold — Wed, 03 Mar 2021 10:15:36 GMT

I guess my issue is trying to figure out what you mean by functionality. As soon as the chip has power there is all kinds of functionality that I cannot do anything about except turn it back off.

When you say "When you start the app timer, the interrupt interval will be the same as the shortest application timer interval you set." does that mean if I have a timer with a hundredth of a second interval and I start any timer (or just create that timer) that sd_app_evt_wait() will be woken up 100 times a second (at minimum)? If that is so it is very important to know!

RE: Wake up sd_app_evt_wait() from application

Hung Bui — Wed, 03 Mar 2021 10:01:49 GMT

I afraid I wouldn't have any other idea other than turning off functionality and use logic trace to track the frequency of waking up to find what caused the issue.

The app timer uses a single RTC to handle timing. When you start the app timer, the interrupt interval will be the same as the shortest application timer interval you set.

RE: Wake up sd_app_evt_wait() from application

brianreinhold — Fri, 26 Feb 2021 13:34:25 GMT

I don't have much to play with. I have not started advertising yet so there are (or should be) no Bluetooth events. The only thing that has happened is the spin up to get the chip operational. I have to press a button to start Bluetooth.

This is all I have and a lot of this is Nordic SDK stuff to initialize the chip.

int main(void)
{
    uint32_t err_code;
    unsigned char cccds[2];

    written = false;
    ghs_abort = false;
    send_live_data = false;
    first_cont_sent = false;
    numberOfStoredMsmtGroups = 0;
    memset(&storedSpot, 0, 30 * sizeof(s_MsmtData));

    // Initialize.
    err_code = NRF_LOG_INIT(NULL);
    APP_ERROR_CHECK(err_code);

    spotGroupLength = 67;

    // Allocate memory for the security keys
    allocateMemoryForSecurityKeys(&keys);
    sec_params_init();
    timers_init();

    memset(&m_sccd_ghs_cp_handle, 0, sizeof(m_sccd_ghs_cp_handle));
    memset(&m_sccd_ghs_response_handle, 0, sizeof(m_sccd_ghs_response_handle));

    memset(cccds, 0, noOfCccds);
    loadKeysFromFlash(&keys, &saveDataBuffer, &saveDataLength, cccds, &noOfCccds);
    memcpy(cccdSet, cccds, noOfCccds);


    buttons_leds_init();

    gpiote_init_new();

    // This also provides the callback method to receive events.
    ble_stack_init();

    // Set device address
    ble_gap_addr_t addrStruct;
    addrStruct.addr_type = BLE_GAP_ADDR_TYPE_PUBLIC;
    memcpy(addrStruct.addr, bluetoothAddress, 6);
    err_code = sd_ble_gap_address_set(BLE_GAP_ADDR_CYCLE_MODE_NONE, &addrStruct);
    if (err_code != NRF_SUCCESS)
    {
        NRF_LOG_DEBUG("Could not set the Bluetooth Address\r\n");
        APP_ERROR_CHECK(err_code);
    }
    // Sets max and min connection intervals, slave latency, and the GAP characteristic entries
    // for the friendly name and appearance.
    gap_params_init();
    // Creates the advertisement and scan response data arrays
    err_code = advertisement_ghs_set();
    if (err_code != NRF_SUCCESS)
    {
        NRF_LOG_DEBUG("Could not configure the advertisements\r\n");
        APP_ERROR_CHECK(err_code);
    }
    // ===================================== Create the GHS service
    err_code = createPrimaryService(&m_sccd_ghs_service_handle, BTLE_SCCD_GHS_SERVICE);
    if (err_code != NRF_SUCCESS)
    {
        NRF_LOG_DEBUG("Could not create GHS service\r\n");
        APP_ERROR_CHECK(err_code);
    }
    // Create the GHS control point characteristic
    err_code = createStandardCharacteristic(m_sccd_ghs_service_handle,
        &m_sccd_ghs_cp_handle,
        BTLE_SCCD_GHS_CP_CHAR,
        true,   // Has CCCD
        true,   // This will cause indicate instead of notify if CCCD is set to true
        0,
        NULL,
        false,
        (ble_gap_conn_sec_mode_t) {1, 1},   // [CCCD write is open]
        (ble_gap_conn_sec_mode_t) {0, 0},   // Reading characteristic value is forbidden
        (ble_gap_conn_sec_mode_t) {1, 1});  // [Writing characteristic is open]
    if (err_code != NRF_SUCCESS)
    {
        NRF_LOG_DEBUG("Could not create GHS control point characteristic\r\n");
        APP_ERROR_CHECK(err_code);
    }
    // ===================================== Create the GHS response characteristic
    err_code = createStandardCharacteristic(m_sccd_ghs_service_handle,
        &m_sccd_ghs_response_handle,
        BTLE_SCCD_GHS_RESPONSE_CHAR,
        true,   // Has CCCD
        false,  // This will cause indicate instead of notify if CCCD is set to true
        0,
        NULL,
        false,
        (ble_gap_conn_sec_mode_t)
        {
            1, 1
        },
        // CCCD write is open
        (ble_gap_conn_sec_mode_t)
        {
            0, 0
        },
            // Reading characteristic value is forbidden
        (ble_gap_conn_sec_mode_t)
        {
            1, 1
        });  // Writing characteristic is open
    if (err_code != NRF_SUCCESS)
    {
        NRF_LOG_DEBUG("Could not create GHS response characteristic\r\n");
        APP_ERROR_CHECK(err_code);
    }
    // Not sure about this yet. I think it allows one to put up a fight to argue 
    // over connection parameters and sets up responses to connection parameter
    // change requests.
    conn_params_init();

    // Start execution.
    err_code = app_timer_start(m_app_dummy_timer_id, CMD_SENSOR_TIME, NULL);
    APP_ERROR_CHECK(err_code);
    elapsedTimeStart = app_timer_cnt_get();
    NRF_LOG_INFO("GHS Pulse Ox Start at time %u!\r\r\n", getTicks());
        
    //=============================================================================== Start GHS Pulse OX
    // Enter main loop.
    main_loop();
}

Unless by initializing SoftDevice and the Buttons so I can press buttons and a single timer is causing these continuous wakeups. Would starting a timer of any type regardless of the frequency of repeats cause events at the rate of the RTC updates? I am not sure how all this hardware works.

If it's not Bluetooth related, I am pretty ignorant as to the possible causes. But I guess an easy first start is to comment out the dummy timer. If that does not change any behavior, I don't really know where to go next.

RE: Wake up sd_app_evt_wait() from application

Hung Bui — Fri, 26 Feb 2021 13:02:39 GMT

Please do what I suggested, turn off the functionality of the program until you see no waking up, and then turn them on one by one. You can start with disable any BLE functionality, no advertising.

RE: Wake up sd_app_evt_wait() from application

brianreinhold — Fri, 26 Feb 2021 10:00:21 GMT

Hung,

I am less concerned about the value of the event (next time I ran it the event id was 26) but why is it waking up at such a high frequency? The only timer I am running before a DK button press is once a second. I have to have that timer in order to use the method app_timer_cnt_get(). I had no idea that this method was being woken up at this high rate. It's pretty important I understand why it is doing that as it will have a big impact upon my implementation. WIll it still behave like this when I put in on a chip and not the DK?

RE: Wake up sd_app_evt_wait() from application

Hung Bui — Fri, 26 Feb 2021 09:26:08 GMT

Hi Brian,
I tried here and it show Soc event 0 continuously. I don't know how you detect id 25.

But I would suggest to only print out "Soc event" only when the err_code from sd_evt_get() return NRF_SUCCESS.
If the chip is waking up from application's interrupt it won't have anything in sd_evt_get.

RE: Wake up sd_app_evt_wait() from application

brianreinhold — Thu, 25 Feb 2021 13:40:12 GMT

I will give you the entire project. You will need the nrf51 DK and putty to view the log. Its a Keil project located here

nrf_SDK_12.3.0\examples\ble_peripheral\ble_app_ghs_pleth\pca10028\s130\arm4

devzone.nordicsemi.com/.../nrfSDK_5F00_12.3.0.zip

Look at the method

static void power_manage(void)

in main.c on line 1954.

RE: Wake up sd_app_evt_wait() from application

Hung Bui — Thu, 25 Feb 2021 13:15:01 GMT

I don't know what could be soc evt id 25. Please provide a minimum code that can reproduce the issue so we can test here.

RE: Wake up sd_app_evt_wait() from application

brianreinhold — Thu, 25 Feb 2021 09:44:58 GMT

That might be nice but all I have at my home is a volt meter and a soldering iron. For me the best chance of finding out what is going on is, perhaps, to just pull the event (I assume it only wakes up due to events) and print what the event is. All I did so far was to print a line of text after the wait was triggered and it came so fast it overflowed in less than a second. I might save some processing power by simply returning if it is not a ble or event that I actually handle somewhere in my loop.

I did print it out and used sd_evt_get() to get the id of the event. The id is 25. And they are flying out at an incredible rate. The documentation says that it is an NRF_SOC_EVTS which is an enum containing only 9 events. What is event 25?

RE: Wake up sd_app_evt_wait() from application

Hung Bui — Thu, 25 Feb 2021 08:39:52 GMT

I would suggest to hook a logic analyzer and do the pin toggling as I did to check the interval of the waking up.

You can try to test turn off functionalities of the application until you don't see the waking up and then turn them back on to see what caused the waking up.

RE: Wake up sd_app_evt_wait() from application

brianreinhold — Wed, 24 Feb 2021 13:02:56 GMT

Well as it turns out SOMETHING (I don't know what) is waking it up all the time; its happening so fast NRF_LOG overflows. I don't know what is waking it up at such a rate. Even before I start advertising this is happening. So I can just set up the data and return in my timer callback and the wait will release. I don't feel very good about that since I don't know what is causing it. I am not intentionally causing those wakeups.

RE: Wake up sd_app_evt_wait() from application

Hung Bui — Wed, 24 Feb 2021 11:41:55 GMT

Hi again,

sd_app_evt_wait() is called inside idle_state_handle().

You should have same result if you have this in the main loop:

for (;;)
{
sd_app_evt_wait();
nrf_gpio_pin_toggle(28);
}
So what I want to show here is that every time you have a timer interrupt (or any application interrupt) and after you are done with the interrupt handler, the function right after sd_app_evt_wait() will be executed. This means the timer interrupt will wake the chip up from sd_app_evt_wait().
The toggling of the pin, is just so that I can show you that the function is executed and the chip is waken up from sd_app_evt_wait(). It can be any function.

You don't need to send a dummy notification or anything to wake the chip up again.

RE: Wake up sd_app_evt_wait() from application

brianreinhold — Wed, 24 Feb 2021 11:08:41 GMT

Okay, then if I understand you correctly, it's a little more complicated than just invoking a timer. I already invoke a periodic timer that when signaled calls a method to generate fake measurements. But it does NOT wake up sd_app_evt_wait(). Now what I want to do is wake up sd_app_evt_wait() after I generate the data.

Its also not clear to me who is doing what your main loop. I assume the 'idle_state_handle()' contains the wait? Maybe not? My main loop is waiting on sd_app_evt_wait(). It is not hiding in any method. Are you saying that there is some method I can call from my timer handler that can toggle a pin on the chip that will release the wait?

Below is the method my timer periodically calls. It generates fake data (it is simulating data coming from another MCU say via SPI or a UART). When generated I would like to wakeup the main loop and return and perform the 'indicate_data()' from the main loop. But that I have been unable to do. So I call the method and that WILL wakeup the main loop eventually due to either the BLE_GATTS_EVT_HVC event or the BLE_TX_EVT_COMPLETE event. But doing so introduces asynchronous behavior - which I want to avoid at all costs.

static void live_data_handler(void * p_context)
{
    UNUSED_PARAMETER(p_context);
    if (send_live_data)
    {
        live_data_count++;
        int i;
        unsigned long timeStamp32 = getTicks();
        NRF_LOG_DEBUG("timestamp32 %lu\r\n", timeStamp32);
        unsigned long long timeStamp = (unsigned long long)timeStamp32 * 1000;
        if (global_indicate.handle != 0)
        {
            NRF_LOG_DEBUG("Not ready for measurement %lu at time %lu\r\n", live_data_count, timeStamp32);
            return;
        }
        #if (HAS_PULSATILE == 1)
        liveMsmt.msmts.hasPulsatile = true;
        liveMsmt.msmts.pulsatile = 523 + (timeStamp32 & 0xFF);
        #else
        liveMsmt.msmts.hasPulsatile = false;
        #endif
        liveMsmt.msmts.spo2 = 95 + (timeStamp32 & 0x03);
        liveMsmt.msmts.pr = 45 + (timeStamp32 & 0x07);
        #if (HAS_PULSATILE == 1)
        NRF_LOG_DEBUG("Measurement added: SpO2 %u%, PR %u, Pulsatile X 100 %u%, timestamp32 %lu, msmt count %lu\r\n", 
            liveMsmt.msmts.spo2, 
            liveMsmt.msmts.pr, 
            liveMsmt.msmts.pulsatile, timeStamp32, live_data_count);
        #else
        NRF_LOG_DEBUG("Measurement added: SpO2 %u, PR %u, timestamp32 %lu\r\n", 
            liveMsmt.msmts.spo2, liveMsmt.msmts.pr, timeStamp32);
        #endif
        if ((live_data_count & 0x07) == 0x00)
        {
            NRF_LOG_DEBUG("Spot msmt to send\r\n");
            liveMsmt.hasTimeStamp = true;
            for (i = 0; i < 8; i++)
            {
                liveMsmt.relTime[i] = (unsigned char)(timeStamp & 0xFF);
                timeStamp = (timeStamp >> 8);
            }
            sendLiveSpotMeasurements(&liveMsmt);
        }
        else
        {
            sendLiveContinuousMeasurements(&liveMsmt);
        }
        indicate_data();  // Here is where I would like to wake up the main loop
    }
}

RE: Wake up sd_app_evt_wait() from application

Hung Bui — Wed, 24 Feb 2021 10:35:32 GMT

Hi Brian,
I'm quite unsure I understand what you meant by "Since I cannot wake up the sd_app_evt_wait()". When you are in the timer interrupt handler you are already waking up (the CPU running) and you are out of the sd_app_evt_wait().

I have made an example for you. This is modified from ble_app_hrs example.
I have this timer in my app:

err_code = app_timer_start(m_battery_timer_id, BATTERY_LEVEL_MEAS_INTERVAL, NULL);

With BATTERY_LEVEL_MEAS_INTERVAL = 200ms.

Then in my main loop I have this:

for (;;)
{
nrf_gpio_pin_toggle(28);
idle_state_handle();
}

You can find the logic trace like this:

This shows that the nrf_gpio_pin_toggle(28) is called every time the battery timer timeout.

So any application interrupt can wake up the chip from sd_app_evt_wait().

RE: Wake up sd_app_evt_wait() from application

brianreinhold — Tue, 23 Feb 2021 16:24:32 GMT

How can I use a timer to wake up sd_app_evt_wait()? I am using the method as a way to emulate a semaphore. So when I get a measurement (say over a UART) I want to encode the measurement, set a flag, and wake up the loop. In the loop the 'indicate_data()" method will be called and an MTU sized hunk of data will be indicated/notified. Then I exit the method and wait for a BTLE event.

IN that manner, the only place I call the indicate_data() method is in that loop which keeps the flow synchronous.

At the moment, I don't have a real sensor so I fake measurements in a timer. Since I cannot wake up the sd_app_evt_wait() I simply call the indicate_data() method from the timer and return. That will cause a ble event. THe down side is that this introduces asynchrony as another event may wake up the loop and indicate_data() will be called from two places.

Lousy non-robust solution.

RE: Wake up sd_app_evt_wait() from application

Hung Bui — Tue, 23 Feb 2021 15:58:11 GMT

Hi Brian,

When exactly you want to wake up from sd_app_evt_wait() ?
The sd_app_evt_wait() only wake up when there is an BLE event or when there is an application event. It doesn't let the application wake up if there is just an BLE event (with no data for example).
You can use the timer to periodically wake the sd_app_evt_wait() up. If you simply want to go back to the top of the loop and can go through sd_app_evt_wait() without waiting there, I think you can set a flag and not calling sd_app_evt_wait() if the flag is set.