Behaviour of PPI endpoint when using extended/periodic advertisement with CTE for direction finding

[ghms]

Hi,

This is a followup on https://devzone.nordicsemi.com/f/nordic-q-a/119259/synchronisation-between-tx-and-rx-in-connectionless-direction-finding 

We now have a synchronised counter being increment on TX and received at RX, which was the key issue in that post. Now, for additional accuracy in timing, we want to toggle a GPIO pin whenever a given packet with CTE is sent. 

In the current setup, I set up the advertisement configuration as follows

static struct bt_le_adv_param param = BT_LE_ADV_PARAM_INIT(BT_LE_ADV_OPT_EXT_ADV | BT_LE_ADV_OPT_USE_IDENTITY,
                                                           BT_GAP_ADV_FAST_INT_MIN_1, BT_GAP_ADV_FAST_INT_MAX_1, NULL);

static struct bt_le_ext_adv_start_param ext_adv_start_param = {
    .timeout = 0,
    .num_events = 1,
};

static struct bt_le_per_adv_param per_adv_param = {
    .interval_min = BT_GAP_PER_ADV_FAST_INT_MIN_1,
    .interval_max = BT_GAP_PER_ADV_FAST_INT_MAX_1,
    .options = BT_LE_ADV_OPT_EXT_ADV | BT_LE_ADV_OPT_USE_NAME | BT_LE_ADV_OPT_NO_2M | BT_LE_ADV_OPT_USE_TX_POWER,
};

and set up the `adv_sent_cb` as

static void adv_sent_cb(struct bt_le_ext_adv *adv, struct bt_le_ext_adv_sent_info *info)
{
    int err;
    memcpy(&adv_data[8], &data_counter, sizeof(uint16_t));

    LOG_INF("Set Periodic Advertising Data to %d", data_counter);
    err = bt_le_per_adv_set_data(adv_set, ad, ARRAY_SIZE(ad));
    if (err)
    {
        LOG_ERR("Failed (err %d)\n", err);
    }

    serialise_counter(&protocol_data, data_counter);
    ble_protocol_data_send_and_clear_buffer(&protocol_data);

    // Guard against overflow
    if (data_counter < 65535)
    {
        data_counter++;
    }
    else
    {
        data_counter = 0;
    }

    LOG_INF("Extended advertising enable...");
    err = bt_le_ext_adv_start(adv_set, &ext_adv_start_param);
    if (err)
    {
        LOG_ERR("failed (err %d)\n", err);
        return;
    }

    LOG_INF("success\n");
}

This works and I am able to receive CTEs at the RX end.

However, with respect to the GPIO toggling, when I set up the following with the intention of toggling the GPIO whenever the payload has been sent with the updated counter value

void ppi_init(void)
{
    NRF_PPI->CH[1].EEP = (uint32_t)&NRF_RADIO->EVENTS_PAYLOAD;
    NRF_PPI->CH[1].TEP = (uint32_t)&NRF_EGU0->TASKS_TRIGGER[0];

    NRF_PPI->CHENSET = PPI_CHENSET_CH1_Set << PPI_CHENSET_CH1_Pos;
}

void egu_init(void)
{
    // Enable EGU interrupt
    NRF_EGU0->INTENSET = EGU_INTEN_TRIGGERED0_Msk;
    NVIC_SetPriority(SWI0_EGU0_IRQn, 6);
    NVIC_EnableIRQ(SWI0_EGU0_IRQn);
}

void SWI0_EGU0_IRQHandler(void)
{
    if (NRF_EGU0->EVENTS_TRIGGERED[0])
    {
        NRF_EGU0->EVENTS_TRIGGERED[0] = 0;

        LOG_DBG("Setting last sent data counter to %d (prev. value = %d)", data_counter, data_counter_last_sent);
    }
}

I get the following output, with the trigger happening five times per extended advertisement packet

but I was only expecting one. My suspicion that it may be related to the fact that periodic advertisement is enabled, but I am not entirely sure, and as far as I can tell, that needs to be active for the periodic sync which receives CTEs on the RX side to function as intended.

Hopefully I've provided sufficient information, please let me know if I need to add additional details!

Kind regards

Glen

[Susheel Nuguru]

Glen,

I am temporarily trying help out this this thread due to the debugging nature of it.

If I read the issue correctly there seems to be two issues here.

First being the multi trigger of the IRQ triggered by PPI events.

I believe that EVENTS_PAYLOAD might not the right choice here. 

Extended advertising works like below, let me see if I can get the alignment right

ADV_EXT_IND   (primary)       ─┬─> [EVENTS_PAYLOAD]
                               │
AUX_ADV_IND   (auxiliary)     ─┬─> [EVENTS_PAYLOAD]
                               │
AUX_SYNC_IND  (periodic)      ─┬─> [EVENTS_PAYLOAD]
                               │
CTE                             ─┬─> [EVENTS_PAYLOAD] (optional, depending on setup)

Each stage may cause EVENTS_PAYLOAD. 

It is better to chose EVENTS_END but this will happen at the end of the packet which should not be an issue based on the description you gave so far.

Second issue, The hardfault is clearly from overuse of allocated stack. It looks like it is the main thread from the logs that overused its stack. Increase the CONFIG_MAIN_STACK_SIZE in your prj.conf. Sometime it might happen that the neighboring thread can corrupt the stack of the other thread. To get a hint of this, it is best to enable CONFIG_THREAD_ANALYZER to get regular updates on the stack use of every thread in your system.

[ghms]

Hi!

Just thought I'd ping this and ask for an update, since it's been a few days since I last responded with updated information.

Kind regards,

Glen

[Susheel Nuguru]

Hi Glen, 

I am sorry, this thread slipped my queue somehow. I apologize for that. 

5 triggers with EVENT_END led me to dig into the extended advertising flow and yeah, it lines up.

The RADIO is firing EVENTS_END at every stage of the TX chain not just when everything is done. So each of these stages in the chain generates its own EVENTS_END.

Here’s the breakdown:

Stage	Event Triggered	IRQ Trigger Context
ADV_EXT_IND (primary)	EVENTS_END	TX_IDLE (1)
AUX_ADV_IND	EVENTS_END	TX_IDLE (2)
AUX_SYNC_IND (periodic)	EVENTS_END	TX_IDLE (3)
AUX_CTE (optional)	EVENTS_END	TX_IDLE (4)
Final TX done	EVENTS_END	TX_ACTIVE (5)

So yeah, it’s not redundant — it’s just that the radio finishes a lot of chunks when you use extended, periodic, and CTE all together. Each EVENTS_END maps to one of those.

ghms said:

could I then just check that we have reached the correct number (in your setup example, since I am sending CTEs, 4 payloads, and then proceed as if things had been successfully transmitted? 

Actually, yes, this seems to be a cleanest solution, do something like this

#define EXPECTED_END_EVENTS 5  // Primary, AUX_ADV, AUX_SYNC, CTE, TX done

static volatile uint8_t events_end_count = 0;

void radio_irq_handler(void)
{
    if (NRF_RADIO->EVENTS_END) {
        NRF_RADIO->EVENTS_END = 0;

        if (++events_end_count == EXPECTED_END_EVENTS) {
            events_end_count = 0;  // Reset for next TX cycle
            process_successful_tx(); // now process the tx
        }
    }
}

[ghms]

Hi Susheel, thanks for your reply. It appears as this does indeed do what is needed, so will verify the answer. Thanks for your help!