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,

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