How to send a sequence of indications?

RE: How to send a sequence of indications?

brianreinhold — Sun, 24 Jan 2021 22:22:05 GMT

Turns out all the issues I was having had nothing to do with indication sequences and handling of the sd_ble_evt_get().

It was NRF_LOG_DEBUG. I guess I was trying to write an array of bytes converted to a HEX string that was too long. I do not know what the limit is, but commenting out that line of code solved the problem. Cost me a week and a half of hair pulling frustration.

Was looking for answers in all the wrong places....

So the approach I took where in the for(;;) loop I handle the sd_app_evt_wait()

followed by the sd_ble_evt_get() with all its own loops but eventual dispatch on

ble_evt_dispatch()

I put the command handler in a one-short timer and set a flag if data needed to be indicated

The indicate_data() method was in that main for(;;) loop. It would only get invoked if the flag was set.

Though the final solution is VERY different than any of the health device examples it works. It might be good if you had an example which illustrated this kind of process. THough it is no semaphore; it accomplishes what a semaphore would have done. But it is much more like a basic embedded loop where you loop through, perform/handle one task, loop again and handle the next and so on.

RE: How to send a sequence of indications?

brianreinhold — Wed, 20 Jan 2021 15:23:47 GMT

Okay, I looked at the thread mode which I am doing or trying to do. However, it contradicts what I have read in the documentation. The docs say that I need to call the sd_ble_evt_get() until I drain all the queued events. That's not what I see in the message flow. The message flow says to call the sd_app_evt_wait() after the call with response NRF_SUCCESS.

I am not doing that now (though things are still not working). Which is correct? cycle through the sd_ble_evt_get() and dispatch event until I get no more events OR call once, dispatch event, call sd_app_evt_wait and repeat?

RE: How to send a sequence of indications?

Vidar Berg — Wed, 20 Jan 2021 13:46:24 GMT

Events are removed from the Softdevice's internal event buffer when you run the event get functions. So, these functions should not be called from multiple places in your code.

You may use the "Thread mode event" retrival approach shown by the sequence chart linked to below if you preffer to poll the SD events from the main loop. Just make sure the Softdevice interrupt is not enabled in that case.

Relevant Message Sequence Charts

Interrupt-driven Event Retrieval

Thread Mode Event Retrieval

Also, a bit back to the original topic, you can take a look at the ancs_tx_buffer.c implementation in the ble_app_ancs_c example to see how we use a ring buffer to queue up multiple indication packets in the application.

RE: How to send a sequence of indications?

brianreinhold — Wed, 20 Jan 2021 09:39:23 GMT

Yes, I found the sd_ble_evt_get() method. The documentation itself is pretty good, but the search engine stinks. It doesn't even find text on the same page that you put into the search bar. I stumbled on this method after methodically looking for every 'function' list I could find in the SoftDevice.

I also did a simple experiment by putting a handler in the that final for-loop and trying each of the sd_*_get() methods that had to do with getting events and printing the results. I didn't try the sd_ble_evt-get() method yet as it was the last one I found.

In my case sd_nvic_GetPendingIRQ(SWI2_IRQn) always returned true and quickly overflowed the print buffer.

I am not using the SDK for a couple of reasons - I want to minimize SDK calls making portability from one chip to another as well as portability to newer versions much simpler. There were HUGE changes in the SDK from s110 v 8 to s130 v 12.3 demanding major code re-writes. However, after converting the old s110 v 8 code to using JUST SoftDevice, moving to s130 was very simple and took but a few minutes. Changes to move from nRF51822 to nRF52840 using just SoftDevice are also minimal. I personally find it easier sticking with BLE fundamentals which SoftDevice gives; you know that every BLE API must be able to perform certain basic tasks. Those I know. Learning how an SDK wrapper works is always a big commitment.

BUT the biggest reason for sticking with SoftDevice only is that I also have code for the pc-ble-driver which ONLY has SoftDevice. It's a great test platform as you can use the PC. Having all code bases as similar and as portable as possible is clearly advantageous.

Now I try sd_ble_evt_get() in my test loop and see what it gives me. First and foremost, who gets the event first. My test loop or my ble event dispatch function that appears in all the Nordic health device examples?

Result of try

Well it looks like the event handler I registered with SoftDevice gets it first and when I get it in the main 'for' loop the event is already drained. So that means (I guess) that I need to call my event handler from my 'test' method where I call sd_ble_evt_get(). AND do NOT register my event handler with SoftDevice. (Does this slow things down?)

The whole purpose is, again, to allow me to call the indication method repeatedly in a 'BUSY' loop without hanging. Since I would be calling my event handler from the main for-loop, the event handler and the timer should all be in the main process. I hope.

RE: How to send a sequence of indications?

Vidar Berg — Wed, 20 Jan 2021 07:38:37 GMT

So I guess you are not using the SoftDevice handler library to retreive and forward Softdevice events as you are trying to implement this mechanism yourself? To get BLE events, you will need to call sd_ble_evt_get(). sd_evt_get() is for SoC events like you said.

[quote userid="83646" url="~/f/nordic-q-a/70569/how-to-send-a-sequence-of-indications/290015#290015"]Do I have to deal with this function: sd_nvic_GetPendingIRQ()? If so, what is the correct IRQn_Type to use? Is it SWI2_IRQn? How would I use this function to get the BLE events?[/quote]

I recommend you review the existing softdevice_handler.c implementation to see how it's done there. You may also want to read up on the ARM Cortex M exception model to get a better understandig of interrupts work on this chip.

sd_nvic_GetPendingIRQ(SWI2_IRQn) is always going return false because the interrupt pending bit is cleared as soon as the interrupt is serviced by the SWI2_IRQHandler (Note: SWI2_IRQHandler is redefined to SOFTDEVICE_EVT_IRQHandler in sdk code). It only makes sense to use sd_nvic_GetPendingIRQ() if the interrupt is masked (ie temporarly disabled)

[quote userid="83646" url="~/f/nordic-q-a/70569/how-to-send-a-sequence-of-indications/290015#290015"]When you say app will wake up you mean my app, correct?[/quote]

Yes, correct. The program will return from the sd_app_evt_wait() call when an application interrupt has been triggered.

[quote userid="83646" url="~/f/nordic-q-a/70569/how-to-send-a-sequence-of-indications/290015#290015"]How do I poll the softdevice event queue? I have not found a method to do that.[/quote]

With sd_evt_get() and sd_ble_evt_get()

RE: How to send a sequence of indications?

brianreinhold — Tue, 19 Jan 2021 13:36:46 GMT

It appears something you have told me is wrong. When sd_app_evt_wait() returns the only function I have at my disposal is sd_evt_get(). This method reports these events according to the documentation:

enum NRF_SOC_EVTS
{
  NRF_EVT_HFCLKSTARTED,                         /**< Event indicating that the HFCLK has started. */
  NRF_EVT_POWER_FAILURE_WARNING,                /**< Event indicating that a power failure warning has occurred. */
  NRF_EVT_FLASH_OPERATION_SUCCESS,              /**< Event indicating that the ongoing flash operation has completed successfully. */
  NRF_EVT_FLASH_OPERATION_ERROR,                /**< Event indicating that the ongoing flash operation has timed out with an error. */
  NRF_EVT_RADIO_BLOCKED,                        /**< Event indicating that a radio timeslot was blocked. */
  NRF_EVT_RADIO_CANCELED,                       /**< Event indicating that a radio timeslot was canceled by SoftDevice. */
  NRF_EVT_RADIO_SIGNAL_CALLBACK_INVALID_RETURN, /**< Event indicating that a radio timeslot signal callback handler return was invalid. */
  NRF_EVT_RADIO_SESSION_IDLE,                   /**< Event indicating that a radio timeslot session is idle. */
  NRF_EVT_RADIO_SESSION_CLOSED,                 /**< Event indicating that a radio timeslot session is closed. */
  NRF_EVT_NUMBER_OF_EVTS
};

These are useless to me and have nothing to do with Bluetooth. How do I get the BLE events?

Do I have to deal with this function: sd_nvic_GetPendingIRQ()? If so, what is the correct IRQn_Type to use? Is it SWI2_IRQn? How would I use this function to get the BLE events?

When you say app will wake up you mean my app, correct?

How do I poll the softdevice event queue? I have not found a method to do that.

RE: How to send a sequence of indications?

Vidar Berg — Tue, 19 Jan 2021 12:28:23 GMT

Application event comes from the interrupts sources listed in the nrf51.h header. I've highlighted those that are reserved to the Softdevice in the image below. Interrupts reserved by the Softdevice are proccessed in the background without invoking the application.

[quote user="brianreinhold"]what events would cause 'my_command_handler' to be called? Would a BLE_GATTS_EVT_WRITE cause the sd_app_evt_wait() to return? Is BLE_GATTS_EVT_WRITE an Application event? [/quote]

The app will wake up on the SD_EVT_IRQn, and then start to poll the Softdevice event queue (BLE_GATTS_EVT_WRITE, etc). It's the SD_EVT_IRQn interrupt that makes the app tor return from sd_app_evt_wait().

[quote user="brianreinhold"]what events would cause 'my_command_handler' to be called? [/quote]

After any of the interrupt shown above, so you will still need to use a bolean flag if you want "my_command_handler()" to only be executed after a certain event.

RE: How to send a sequence of indications?

brianreinhold — Mon, 18 Jan 2021 18:46:33 GMT

It's still not clear to me what an application event is. As I stated I hoped that I could use this wait() to replace a semaphore.

If I have something like this (the power_manager() has the sd_app_evt_wait() )

    for (;;)
    {
        if (NRF_LOG_PROCESS() == false)
        {
            my_command_handler();
            power_manage();
        }
    }

what events would cause 'my_command_handler' to be called? Would a BLE_GATTS_EVT_WRITE cause the sd_app_evt_wait() to return? Is BLE_GATTS_EVT_WRITE an Application event? If so that would be great (as long as the event handler that I have initialized with the soft device gets called first).

I have read the docs on these methods over and over again but there were so many things (like application events) that I just could not figure out what was meant.

It would be SOOO helpful if someone would say exactly what an 'application' event is. I write the application, but I clearly do not define these events. Are application events ALL events received by the application? In the docs they talk about SoftDevice events and don't call them application events. So what is the story?

RE: How to send a sequence of indications?

Vidar Berg — Mon, 18 Jan 2021 16:37:46 GMT

As stated in the API documentation for sd_app_evt_wait(), an application event is either an application interrupt or a pended interrupt when the interrupt is disabled. An example of this is when the RTC1 interrupt gets triggered inside the app_timer module. This interrupt would then make your program return from the sd_app_evt_wait() function.

[quote user="brianreinhold"]Also, enumerations like BLE_GATTS_EVT_WRITE are events, not interrupts as I understand it.[/quote]

Yes, you've understood it correctly. These are internal Softdevice events.

The Softdevice triggers the SOFTDEVICE_EVT_IRQ interrupt to let the application know when new Softdevice events are available, and the application will then retrieve the the events by calling sd_evt_get() and sd_ble_evt_get() while still inside the Softdevice interrupt handler.

[quote user="brianreinhold"]If I were sending notifications instead of indications would it still be so complicated? Many vendors send sequences of data but I don't know if they use Nordic chips. But they also use notifications instead of indications.[/quote]

Notifications are a bit easier to deal with as you can queue up multiple notifications at a time. Though, instead of handling busy errors, you will have to handle the NRF_ERROR_NO_TX_PACKETS error if the notification output queue becomes full.

Also, I took a screenshot from Keil to try illustrate how Softdevice events are being propagated to the on_ble_evt() handler from the Softdevice interrupt. Let me know if you have questions to this.

on_ble_evt() invoked in interrupt context:

RE: How to send a sequence of indications?

brianreinhold — Mon, 18 Jan 2021 13:39:30 GMT

Now that just adds to the confusion. I have long looked at this function as a hopeful solution to many problems but I have never been able to understand what an 'application event' was. In most contexts that I have worked in, 'application' is what I write on top of an SDK. But if that is true, I would expect I could define an event but I cannot. So how do I wake this thing up? Once called does it wake on every event such as a BLE_GATTS_EVT_WRITE?

Also, enumerations like BLE_GATTS_EVT_WRITE are events, not interrupts as I understand it. Well they are are called events. Maybe not? When I receive a GATTS or GAP event, am I back on the main context? Or am I only in the main context if I am in the main function? So am I forced to be that for loop which is now occupied by the 'power_manage()' method?

If I were sending notifications instead of indications would it still be so complicated? Many vendors send sequences of data but I don't know if they use Nordic chips. But they also use notifications instead of indications.

RE: How to send a sequence of indications?

Vidar Berg — Mon, 18 Jan 2021 13:21:53 GMT

By calling sd_app_evt_wait(), or __WFE() if the Softdevice is disabled.

RE: How to send a sequence of indications?

brianreinhold — Mon, 18 Jan 2021 13:14:08 GMT

Simple question that's not so simple - How does one invoke a sleep as you reference in this system?

RE: How to send a sequence of indications?

Vidar Berg — Mon, 18 Jan 2021 13:02:42 GMT

[quote userid="83646" url="~/f/nordic-q-a/70569/how-to-send-a-sequence-of-indications/289725#289725"]Since I cannot send data until the client asks for it via a BLE_GATTS_EVT_WRITE event, I invoke a timer and when the timer completes, I invoke the call. I do not know if that is in the main context or not. [/quote]

Is it the SDK app timer? In that case, you will have to use it with the app scheduler as Einar explains in the nRF5 SDK Scheduler Tutorial. The timer handler will be invoked in an interrupt context if not.

[quote userid="83646" url="~/f/nordic-q-a/70569/how-to-send-a-sequence-of-indications/289725#289725"]This sounds messy and inefficient. But you still have not answered my question about NRF_ERROR_BUSY. If I get that response is it the case I MUST recall the method? If I do not, the data will not be indicated. OR can I just wait?[/quote]

The data will only be sent if the call returned NRF_SUCCESS

[quote userid="83646" url="~/f/nordic-q-a/70569/how-to-send-a-sequence-of-indications/289725#289725"]By the way, does an nrf_delay_ms(50); count as a sleep?[/quote]

No, it's a busy wait. The CPU will execute a bunch of NOPs as you said.

RE: How to send a sequence of indications?

brianreinhold — Mon, 18 Jan 2021 12:54:51 GMT

Since I cannot send data until the client asks for it via a BLE_GATTS_EVT_WRITE event, I invoke a timer and when the timer completes, I invoke the call. I do not know if that is in the main context or not. If the only way to call it from the main context is in that infinite for-loop that means basically I have to put my whole command handler in there and wait on it to be triggered. In the pc-ble-driver case I do, but I use a semaphore so it works like a charm. Now I guess the only way to do this with some efficiency is to wait on a volatile boolean triggered in the BLE_GATTS_EVT_WRITE event and after the first trigger reset the sleep to a much shorter time.

This sounds messy and inefficient. But you still have not answered my question about NRF_ERROR_BUSY. If I get that response is it the case I MUST recall the method? If I do not, the data will not be indicated. OR can I just wait?

By the way, does an nrf_delay_ms(50); count as a sleep? My understanding is that this is also a full throttle tag of the CPU with a bunch of NOPs. It does not solve the problem but I only have 50 ms so far.

RE: How to send a sequence of indications?

Vidar Berg — Mon, 18 Jan 2021 12:43:17 GMT

Ok, maybe it doesn't make sense to use an actual semaphore as this is an interrupt driven system without a task scheduler. But you can still use a boolean flag like I suggested.

[quote user="brianreinhold"]That for-loop looks deadly - will completely floor the processor; running an infinite loop as fast as the processor can go.[/quote]

That's true only if you don't call the sleep function after processing the if statements.

[quote user="brianreinhold"]Now if I do that, what happens if a get an NRF_ERROR_BUSY? Do I have to call again or is it so that the first call will eventually complete if I wait long enough? [/quote]

Yes, you can implement retries. It should not get stuck if you are doing it from the main context.

RE: How to send a sequence of indications?

brianreinhold — Mon, 18 Jan 2021 12:19:48 GMT

How do you use a semaphore in s130 SDK 12.3.0 - as I stated in the initial post I can't do that. There is no such thing in SDK 12.3.0! My ideal solution would be to create a semaphore, indicate the data, wait on that semaphore, and release the semaphore in the BLE_GATTS_EVT_HVC. But that is not possible.

That for-loop looks deadly - will completely floor the processor; running an infinite loop as fast as the processor can go.

I do not think I am calling it from an interrupt context. In the BLE_GATTS_EVT_WRITE event where I 'call' the send data method, all I do is invoke a timer. When the timer expires, it calls the send data. It is there where I get three indications out and then it stops.

So given you are using a full-throttle for-loop that tags the CPU I suppose I could do the same thing in my sender. Just do a while loop on the wait_for_hvc. That's what a semaphore does after all without flooring the processor because the semaphore stops the thread from eating up CPU.

Now if I do that, what happens if a get an NRF_ERROR_BUSY? Do I have to call again or is it so that the first call will eventually complete if I wait long enough? Otherwise it seems like a catch-22. I can't retry a BUSY because it might become stuck, but if I get a busy and then do a full throttle while loop wait, the call will never complete because of the BUSY.

None of this makes too much sense. If I tag the processor in that for or while loop, how is it going to get anything done?

RE: How to send a sequence of indications?

Vidar Berg — Mon, 18 Jan 2021 12:05:14 GMT

Hi,

sd_ble_gatts_hvx() may get stuck with the NRF_ERROR_BUSY error if you're calling it from an interrupt context as it may block the BLE_GATTS_EVT_HVC Softdevice event from ever coming through. A solution to this can be to send the data from your main loop instead, and either use a flag or a semaphore to know when you have received the BLE_GATTS_EVT_HVC event.

/* Flag to wait for pending 
 * Handle Value Confirmation 
 */
static volatile bool wait_for_hvc; 

/* This function is invoked in the Softdevice interrupt context
   unless you are using a scheduler */
static void on_ble_evt(ble_evt_t * p_ble_evt)
{
    uint32_t err_code;

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GATTS_EVT_HVC:
            wait_for_hvc = false;
    ..
..

int main(void)
{
    ...
    for (;;)
    {
        if (<send data>)
        {
            send_data();
            wait_for_hvc = true;