What is an Application Event?

[brianreinhold]

I am searching for a straight answer to this question. 'Application event' is used frequently in the documentation but never defined. I write the application but I clearly do not define these events. Initially I assumed they were events I defined and I could use them with sd_app_evt_wait(). Alas that is not the case.

So what is an application event?

All events received by my application?

If I know what an application event actually is, then I might be able to use sd_app_evt_wait(). If SoftDevice events (such as all the Bluetooth GAP and GATT events) are 'application events', I might be able to use sd_app_evt_wait() to support semaphore-like behavior that I really need.

Someone please tell me what 'application events' are and give some examples! It would also be helpful to tell me what events received by my application from SoftDevice are NOT 'application events'.

I guess while your at it, can you tell me what application interrupts are? These sound more like interrupts I define unlike application events.

[Karl Ylvisaker]

Hello,

I write the application but I clearly do not define these events. Initially I assumed they were events I defined and I could use them with sd_app_evt_wait(). Alas that is not the case.

Please see the answer by my colleague Susheel in this ticket.

So what is an application event?

All events received by my application?

In essence, yes. Application events are the subset of all the possible events, that is passed to the application - for instance, many of the events are only used by the SoftDevice, and thus not forwarded to the Application layer.
You may use the NRF_SDH_BLE_OBSERVER macro to forward BLE events to handlers in your application.

I might be able to use sd_app_evt_wait() to support semaphore-like behavior that I really need.

Could you elaborate on exactly what this behavior you are looking for is?
Are you developing with the nRF5 SDK, or nRF Connect SDK? In the case of the latter you should know that Zephyr is an RTOS that already provide this for you.

I guess while your at it, can you tell me what application interrupts are? These sound more like interrupts I define unlike application events.

The explanation here is the same as for the application events - the application interrupts are the subset of interrupts which are passed to and handled by the application.
An example of this would be a TIMER instance that you setup to periodically trigger an interrupt in your application - this is an application interrupt.
An example of a 'non-application interrupt' would be the SoftDevice's own timers interrupt, which are never seen by the application.

Please let me know if anything should still be unclear, or if you encounter any other issues or questions.

Best regards,
Karl

[brianreinhold]

First I am not using the SDK for any Bluetooth, but only SoftDevice, I have several good reasons for that, but mainly that I am working with the BT SIG Med group to define a single generic health device standard that can be used for all devices. Also I am using the pc-ble-driver for the same purpose. (Here I am writing for the nRF51822 to use on a real device.) Nice to have the two as similar as possible.

The problem I am trying to solve is the simulation of a semaphore. I have a characteristic value that is several MTUs long, so I indicate, need to wait for the response event, and repeat. The start of the sequence is given when the peer writes a command to do so. I have another posted thread on this site about that. But in that thread and in the documentation there are endless references to 'application event' without ever defining what that was.

Thus this post to get a straight concrete answer so I can move forward and have a better understand of what my options are. Being able to 'indicate' long characteristic values is central to this standard. Right now when I do a while loop on the sd_ble_gatts_hvx() call and the NRF_ERROR_BUSY it hangs after about three indications. I am calling the method from a timer started in the ble event handler.

[brianreinhold]

Karl, I am doing the classic 'busy' loop when calling the sd_ble_gatts_hvx(). I am discussing that in another thread. But what you have said contradicts the information I am getting in another thread. If I get an NRF_ERROR_BUSY I need to try again. If I don't it is as if that call was never made.

Now ideally what I wanted to do  ( and did do in the pc-ble-driver) is make the sd_ble_gatts_hvx()  call and wait on a semaphore. WHen I got the BLE_GATTS_EVT_HVC event, I released the semaphore. Worked great. No such tool here. So all the issues I am having are related to trying to simulate the functionality of a semaphore.

OH, by the way, when I say I am not using the SDK, I mean I am using sd_* calls for all BLE functionality and anything else that I can do (flash writing for example).

The other thread is

 https://devzone.nordicsemi.com/f/nordic-q-a/70569/how-to-send-a-sequence-of-indications

That's how application events came up and I could not get a clear answer on what they were. In the end it appears to be any event that is passed up to my application.

[Karl Ylvisaker]

Hello,

Thank you for your patience.

brianreinhold said:

But what you have said contradicts the information I am getting in another thread. If I get an NRF_ERROR_BUSY I need to try again. If I don't it is as if that call was never made.

I am not exactly sure what contradicting information you are referring to, but it is correct that you will need to try again if you get an error - any returned error code != NRF_SUCCESS indicates that the returning function did not succeed for whatever reason, so if you intend to have that packet transferred it will need to be tried again - this is also written in the documentation I referenced. So, your assessment here is correct.
If this is not the contradicting part, please elaborate on what I have said that contradicts prior information, so we could clear up any possible misunderstandings.

brianreinhold said:

Now ideally what I wanted to do  ( and did do in the pc-ble-driver) is make the sd_ble_gatts_hvx()  call and wait on a semaphore. WHen I got the BLE_GATTS_EVT_HVC event, I released the semaphore. Worked great. No such tool here. So all the issues I am having are related to trying to simulate the functionality of a semaphore.

I see. Are you doing the sd_ble_gatts_hvx call as part of a interrupt handler or from the main context like suggested by my colleague Vidar in your other ticket? - if you are calling it from an interrupt handler, what is the priority of this interrupt configured to?
My suggestion here would be close to what Vidar already has suggested for you - if you receive a BUSY error, place the indication in a queue and wait for the BLE_GATTS_EVT_HVC after which you try it again. This should work, but you will also have to ensure that there is no pile-up of unsent indications by checking the the rate of new indications vs. the rate of indications going through. Since the indication requires an application level ACK it will at least be 1 full connection interval until this is received.

brianreinhold said:

OH, by the way, when I say I am not using the SDK, I mean I am using sd_* calls for all BLE functionality and anything else that I can do (flash writing for example).

 Thank you for clarifying.

Best regards,
Karl

[brianreinhold]

I am calling from the main context (as suggested).

THe contradiction I am talking about is that the message sequence does NOT do any retries. It simply calls the ble get event and then the wait. That's not what the docs say. They say I need to re-call the ble get event method if I get an event. That is not present in the message sequence - it is not mentioned.

So what you are saying is that I must do the loop on the get event until I get no more events before calling the wait (regardless of what the message sequence diagrams).

So lets take a look at what you are suggesting:

First I have an array of 200 bytes to indicate using an MTU of 23 so I get 20 bytes per indication.

I call the sd method to send the indication

now what I would like to is wait for the event indicating it was acked.

If I get a busy, call again with no wait.

If I get a success, wait for the ack event using the sd_wait and sd_ble get event methods in a loop unitl I get what I want, jump back to the outer loop where I send the next 20 bytes.

Is this correct?

[brianreinhold]

Second reply.

This is getting very frustrating as none of these approaches are working. They all hang, and due to the NRF LOG restrictions I cannot find what is hanging. The furthest I have been able to get was before I did all this 'main thread' things and was just using the classic ble dispatch handler as used in the health device examples. I did a while loop on the sd_indicate method until not busy. I got as far as three indication sequences before hanging.

So I am clearly missing a critical piece of information - I just don't know what. I went and looked at the void intern_softdevice_events_execute(void) handler in the softdevice_handler.c file to see if I could find some hints. This method dispatches events to my app if I register in the normal way. I see the void intern_softdevice_events_execute(void) method is called by void SOFTDEVICE_EVT_IRQHandler(void). However, the intern_softdevice_events_execute(void) enters an infinite loop and only exits if the user suspends the handler.

I find this confusing as it seems like SOFTDEVICE_EVT_IRQHandler(void) would be called several times and invoke the intern_softdevice_events_execute(void) which is already in an infinite loop. I do not see any use of the sd_app_evt_wait() method.

There must be an easier way to do this; it's such a basic need! Clearly one must face this need all the time; indicate a sequence of data! Is it best to go back to the standard approach used in the health device examples and figure out why the wait on busy loop freezes? I got further using that approach than doing anything else, and all just using sd_ calls.

What happens if I invoke sd_app_evt_wait() in more than one place? For example in the standard for(;;) loop all the examples use and after doing something like 

    error_code = sd_ble_gatts_hvx(m_connection_handle, &hvx_params);
    sd_app_evt_wait();

[brianreinhold]

I have to reply here as this site is once again messing up and there is no reply button to the reply I need to reply to. One of these days this site will get fixed!

Just wanted to say all my problems were due to NRF_LOG_DEBUG. Printing a string that was too long I guess. Don't know. But removing it solved all my issues. That aside, at least I know what an application event is.

[Karl Ylvisaker]

Hello again brianreinhold,

brianreinhold said:

I have to reply here as this site is once again messing up and there is no reply button to the reply I need to reply to. One of these days this site will get fixed!

I am sorry to hear that your experience with the site is not up to par - we're continuously working on making the forum better, and I will submit this as an issue internally to be looked into.

brianreinhold said:

Just wanted to say all my problems were due to NRF_LOG_DEBUG. Printing a string that was too long I guess. Don't know. But removing it solved all my issues. That aside, at least I know what an application event is.

Thank you for the update - I am happy to hear that you were able to identify and resolve all your issues!
To limit the effects that the logger module has on your program you may want to use the deferred_logging option of the logger. This will allow you to process loggings only when you have the time, and not where the call to NRF_LOG_DEBUG is actually made. You can see how this is implemented as part of most example's idle_state_handler. 

Regarding your previous comment on the contradiction I am unfortunately still not seeing where my answer contradicts the documentation - you're interpretation of my suggestion regarding the sending loop - retry if != NRF_SUCCESS is returned, wait for application layer ack before sending next - is correct.

Please do not hesitate to open a new ticket if you should encounter any issues or questions in the future.

Good luck with your development!

Best regards,
Karl

[brianreinhold]

The main problem I have with the site is the 'reply' button not being displayed. It is shown after some posts but not all them. Someone figured out a clever way to make it display, but it does not always get all of the missing ones.

In any case the contradiction I was mentioning is the between the message diagram and the text description for the sd_ble_evt_get(). The message diagram shows no repeat of the sd_ble_evt_get(), the sd_ble_evt_get() is done once and then one is back to the sd_app_evt_wait().

If I had ONLY looked at the diagram, I would not have looped over the sd_ble_evt_get() until I got no more events. Given the issues I was having I tried all kinds of combinations (many made no sense but one got desperate)!

As far as the logging goes I do use the deferred approach and process the log in that final for(;;) loop used in all the examples. So It has something to do with the size of the string. If the string is short, no problem. But when it is not, it freezes. I do use the nrf_log_push() to contain the string.

In any case, I cannot use the log when I deploy it on the actual device (I assume). All I have connecting the actual device to Keil is the SWD interface on the DK.

Here is my final loop

static void main_loop(void)
{
    uint8_t enabled;
    uint16_t len;
    uint32_t result;
    for (;;)
    {
        indicate_data();        // when flag is set, a set of data is indicated. Flag reset in method
        main_wait();            // Contains the sd_app_evt_wait()
        while(true)
        {
            sd_softdevice_is_enabled(&enabled); // Don't do this if disabled, for example when writing flash at the end
            if (enabled != 1)
            {
                break;
            }
            result = sd_ble_evt_get(NULL, &len);    // Get sixe of event
            if (result == NRF_ERROR_NOT_FOUND)      // If there aren't any, go back to wait
            {
                break;
            }
            evt_buf = (uint8_t *)calloc(1, len);                // Make space for event
            result = sd_ble_evt_get((uint8_t *)evt_buf, &len);  // get the event
            if (result == NRF_SUCCESS)
            {
                ble_evt_t *evt = (ble_evt_t *)evt_buf;
                ble_evt_dispatch(evt);                          // dispatch event to handler
                NRF_LOG_PROCESS();                              // SHould I do this here to get a tighter display of log?
            }
            else                                                // Hopefully no error but just in case log it.
            {        
                #if (USE_DK == 1)
                NRF_LOG_DEBUG("PENDING BLE Event return error: %u\r\n", result);
                #endif
                free(evt_buf);  // Clean up
                break;          // back to wait
            }
            free(evt_buf);      // clean up and get the next event
        }
    }
}

I get an APP:ERROR:FATAL when I write to flash (pairing and bonding data) but the write succeeds. On a reconnect all the data is present and valid. This is the only scar remaining though it odes not affect performance. After the data is sent, the nrf51822 disconnects, disables SofDevice, writes to flash (only on a first time connect) and then has no more do. 

What is the proper way to shut down? Exit from the above loop?

[Karl Ylvisaker]

Hello,

brianreinhold said:

I get an APP:ERROR:FATAL when I write to flash (pairing and bonding data) but the write succeeds.

That sounds strange. Could you paste me the entire error message?

brianreinhold said:

If I had ONLY looked at the diagram, I would not have looped over the sd_ble_evt_get() until I got no more events.

I understand how this could cause confusion. However, I would also argue that it is unwise to use most any function without first reading its API reference documentation. In this case, it is thoroughly explained in the sd_ble_evt_get documentation, which reads:

This call allows the application to pull a BLE event from the BLE stack. The application is signaled that an event is available from the BLE stack by the triggering of the SD_EVT_IRQn interrupt. The application is free to choose whether to call this function from thread mode (main context) or directly from the Interrupt Service Routine that maps to SD_EVT_IRQn. In any case however, and because the BLE stack runs at a higher priority than the application, this function should be called in a loop (until NRF_ERROR_NOT_FOUND is returned) every time SD_EVT_IRQn is raised to ensure that all available events are pulled from the BLE stack. Failure to do so could potentially leave events in the internal queue without the application being aware of this fact.

Undoubtedly I also agree that all documentation should point in the same direction, to avoid any confusion. Could you link the exact diagram in question here for me, so I could mark it for internal review? 

brianreinhold said:

Given the issues I was having I tried all kinds of combinations (many made no sense but one got desperate)!

I think absolutely all programmers can relate to this! :) 

brianreinhold said:

What is the proper way to shut down? Exit from the above loop?

When you say shut down, do you mean SYSTEM_OFF?
If you are using the same sleep loop as from the examples you may use sd_power_system_off function to enter SYSTEM_OFF. Keep in mind that the only way to wake from SYSTEM_OFF is with a reset, and thus you will have to setup a way to reset(such as the push of a button) if you intend for your device to wake up again.
How to configure wakeup from SYSTEM_OFF is demonstrated in most of the BLE examples in the SDK, such as the Heart Rate monitor example's sleep_mode_enter function.

brianreinhold said:

In any case, I cannot use the log when I deploy it on the actual device (I assume). All I have connecting the actual device to Keil is the SWD interface on the DK.

You may use the logger module on a third party device without a debugger, but you will then be forced to use the loggers UART backend, which leaves you without UART for the rest of your application. You can read more about the logger library here.

Best regards,
Karl

[brianreinhold]

Karl,

When things are not working and you see two different methods in the documentation, you don't know which is right, especially when you try both and neither works. It turned out the problem was the NRF_LOG; I was looking for errors in all the wrong places.   In any case, the message sequence diagram in the s130 for the Thread Mode Event Retrieval is incorrect.

The APP:ERROR:ERROR:Fatal was due to me disabling softdevice and then calling the sd_app_evt_wait() method.. The docs indicate that it can only return NRF_SUCCESS, so I never checked.

Since I use the UART in the production device to talk to the sensor MCU, I cannot use the log.

Wnen I shut down, the device will power off. In the end I do a reset so I dont have to re-enable the softdevice.

[Karl Ylvisaker]

brianreinhold said:

When things are not working and you see two different methods in the documentation, you don't know which is right, especially when you try both and neither works.

Yes, as I said - I can completely relate to this.

brianreinhold said:

In any case, the message sequence diagram in the s130 for the Thread Mode Event Retrieval is incorrect.

Yes, thank you for pointing that out. I have created an internal ticket for this issue and marked it for review.

brianreinhold said:

The APP:ERROR:ERROR:Fatal was due to me disabling softdevice and then calling the sd_app_evt_wait() method.. The docs indicate that it can only return NRF_SUCCESS, so I never checked.

I am glad that you were able to identify the cause of the issue, and I must urge you to always check all returned error codes, since this is the only way for you to know that a function has failed (for whatever reason), and that the program can not proceed as normal - this is especially useful to catch and resolve transient errors.

brianreinhold said:

Since I use the UART in the production device to talk to the sensor MCU, I cannot use the log.

Yes, then your options are limited. If you intended to use the logging for debug purposes after deployment, could it be an option to have it saved to flash instead?

Best regards,
Karl