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]

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

[brianreinhold]

Karl,

That being said, it would be helpful if the documentation on sd_app_evt_wait()  were updated. At the moment it says only one code is returned; NRF_SUCCESS. Why check when you know what it is? In any case there is a second code it can return and that is NRF_ERROR_SOFTDEVICE_NOT_ENABLED. I do not know if it can return additional codes. Again, this is s130. It may be corrected in later versions of SoftDevice but this is the latest version I can use with nrf51822.

With respect to using flash I would assume that would take quite a bit of flash memory. Right now I am stuck with using the last page (as in the example) because I do not know how to programmatically obtain the first free page available. At the moment I do not need much space so the last page suffices.

The example does not illustrate or explain how one can programmatically obtain the location of the next free space after the application is loaded, or even the next free page. Application size is dynamic; it changes for every change you make in the source.

Eventually when the manufacturers decide to support a trickle charge so the RTC can run while not in use, I would like to be able to store data (stored data requires a time stamp by spec). Then I would like to make use of a lost more flash and the last page will not be enough.

[Karl Ylvisaker]

brianreinhold said:

That being said, it would be helpful if the documentation on sd_app_evt_wait()  were updated. At the moment it says only one code is returned; NRF_SUCCESS. Why check when you know what it is?

I certainly see your point here - but I would again argue that error codes should always be checked, no matter what, if it is specified that an error code is to be returned.
I wholeheartedly agree that the documentation should reflect that there exists a possibility of a != NRF_SUCCESS error code return.
I will add this as a second documentation review request.

brianreinhold said:

With respect to using flash I would assume that would take quite a bit of flash memory. Right now I am stuck with using the last page (as in the example) because I do not know how to programmatically obtain the first free page available. At the moment I do not need much space so the last page suffices.

I do not know anything about the size of your application, but I am happy to hear that you found the functionality of the logger module helpful and that you have found a solution that works out for you for the time being.

brianreinhold said:

The example does not illustrate or explain how one can programmatically obtain the location of the next free space after the application is loaded, or even the next free page. Application size is dynamic; it changes for every change you make in the source.

Which example are you referring to here?
I am not sure I understand the last part of your comment here - the application size is not dynamic in the sense the word dynamic in relation to memory is usually used.
Unless you are working with dynamic memory allocation in your application?

Best regards,
Karl

[brianreinhold]

The example I am referring to it the demo 'write to flash' example. By dynamic I mean the size of the application I write will be dynamic, As I add/change code the size of its footprint will change. What would be nice in the example is if they would illustrate how to find the first free area of flash so you would have the maximum amount of storage available. I do not store measurement data in my example but I want to. In order to do that I will need more than the last page.

[Karl Ylvisaker]

brianreinhold said:

The example I am referring to it the demo 'write to flash' example.

Thank you for clarifying.

brianreinhold said:

By dynamic I mean the size of the application I write will be dynamic, As I add/change code the size of its footprint will change.

That is true - the memory requirement of the application will certainly change during development.
If you do not want to update your memory map for each time this happens, you could make due with a smaller partition during development, and then resize it once the development of the application is done.

brianreinhold said:

I do not store measurement data in my example but I want to. In order to do that I will need more than the last page.

Have you taken a look at the Flash Storage and Flash Data Storage examples? They demonstrate the usage of both the fstorage and fds library.
It sounds like either of them could be a good fit for the use-case you describe.

Best regards,
Karl

[brianreinhold]

I have looked at them a little bit but I am not using the SDK but SoftDevice. That is because I am also using pc-ble-driver with similar code. There is no SDK for that.

I did search through the code to see if I could find some indication has how the end of used flash could be obtained programmatically. I already write to flash using the last page, so writing to flash is not the problem. Its programmatically finding where to start.

However, it sounds like you are saying that it is an impossible task. I have to manually hard code the start location based upon reading a map file every compile - then recompile.

[Karl Ylvisaker]

brianreinhold said:

I have looked at them a little bit but I am not using the SDK but SoftDevice. That is because I am also using pc-ble-driver with similar code. There is no SDK for that.

Yes, I have understood this - but I have not quite understood your aversion to using the SDK for your firmware developing. Could you elaborate on why this is so?
As mentioned the pc-ble-driver is just a serialized SoftDevice API, so there really is not a lot to go on in terms of creating an SDK for the pc-ble-driver, unless you by this mean that there should be an array of examples using the pc-ble-driver akin to the SDK's examples?

brianreinhold said:

However, it sounds like you are saying that it is an impossible task. I have to manually hard code the start location based upon reading a map file every compile - then recompile.

Well, both yes and no. If you insist on not using any parts of the SDK other than the SoftDevice API, then yes, you will have to keep track of the size of your application yourself. However, if you open for using the SDK then you will have multiple options.
For example, with you current setup you may use the CODE_START, CODE_END, and CODE_SIZE define's from the app_util.h file.
Or, you may use the fds or fstorage libraries, as they both start at the top of the Flash(also checking if there is a bootloader present and proceeding accordingly), and writes downwards.

Again, I would recommend that you do make use of the SDK components instead of implementing these things yourself - it will save you a lot of time and work.

Best regards,
Karl