SCAN_REQ and SCAN_RSP logging

[Felipe1]

Hello, I have a question about the scan request event.

I checked the logs of BLE_GAP_EVT_SCAN_REQ_REPORT.  If this event is received, does Softdevice recognize the packet as SCAN_REQ properly and surely send back SCAN_RSP?  If there are any problems in receiving a SCAN_REQ packet (e.g. CRC error), can I see any logs/messages?  Or if there are any problems in sending a SCAN_RSP packet, can I see any logs/messages as well?

I am looking for any tools/methods to make sure the scan response procedure works in the software level.

[Environment]

nRF52832 custom board

nRF5 SDK 17.1.0

Softdevice S132 v7.0.1, 7.2.0, 7.3.0

Sample source code : ble_peripheral\ble_app_blinky

 

[Modification]

I added the following lines in main.c and built a debug module.  The log messages are seen.

// In advertising_init

    adv_params.scan_req_notification  = 1;

 // In ble_evt_handler

         case BLE_GAP_EVT_SCAN_REQ_REPORT:

            NRF_LOG_INFO("SCAN_REQ");

            break;

[Felipe1]

Hi Vidar and Nordic Semi support, I could not reply to you sooner.
I could not use a shielded box, but I got Nordic PPK2 and tested some more cases.
I've got a new question. Sorry for my lengthy post, but any comments would be greatly appreciated.

[Test purpose]
To understand the relationship between the current waves of scan request and scan response and the softdevice procedure.

[Environment]
nRF52 DK (solder bridge SB9 has been cut)
nRF5 SDK 17.1.0 ble_app_blinky (pca10040/S132) modified like these:
to set TX power to 4dBm to differenciate TX and RX current waves.
to turn on/off LED4 en BLE_GAP_EVT_SCAN_REQ_REPORT is received.
to turn on/off LED3 when CRC error is received.
Nordic PPK2 (digital port D0 is connected to P0.20 (LED4), D1 is to P0.19 (LED3))
nRF Connect for Desktop - Power Profiler (Ampere Meter)
nRF Connect for Mobile + Android Smart Phone (Clicking "SCAN" during the current measurement in order to enforce the active scan)

[Result 1]
This is nRF52832 current wave, including D0 (BLE_GAP_EVT_SCAN_REQ_REPORT) and D1 (CRC error).
In case the smart phone is nearby (RSSI is high), some CRC errors were seen (e.g. 12 times in 30 sec).

In case the smart phone is far (RSSI is low), more CRC errors were seen (e.g. 61 times in 30 sec).

[Result 2]
Looking into the above "far" current graphs, the following 4 patterns were seen.
1. BLE_GAP_EVT_SCAN_REQ_REPORT is received. SCAN_RSP is sent, and then post procedure is done (~8mA current consumption continues).

2. CRC error is received, then the post procedure is done (~8mA current consumption).

3. No event is received. ~8mA current consumption is not seen. No packet was received during this advertisement.

4. Like case 3, no event is received.  But ~8mA current consumption is seen.

[Question]
Pattern 1, 2, and 3 are understandable. But I cannot understand pattern 4. Why ~8mA consumes even though packet is not received regardless of CRC?

Thank you.  Toru

[Vidar Berg]

Hi Toru,

Do you have any application interrupts enabled when you run this test (apart from the SW interrupt used for monitoring the CRC error event? 

Best regards,

Vidar

[Felipe1]

Hi Vidar,

Thank you for your comments.  No, the app is slightly modified ble_app_blinky only.  Do I miss anything in your question?

Thank you,

Toru  

[Vidar Berg]

Thanks Toru. Yes, that answered my question. Still, it is not clear to me why the CPU is seemingly running after the advertisement event in the case where you did not receive the scan request.

Are the output pins shown in shown in your screenshots toggled in SW or in HW with the help of PPI? 

[Felipe1]

Hi Vidar,

Thank you for your Info. For the BLE_GAP_EVT_SCAN_REQ_REPORT event detection, I am using the Softdevice SoC event handler just like the other BLE events like connected, disconnected, and others. For CRC error event detection, I referred to your snippet and I am using the software interrupt with the help of PPI. For both cases, I am calling bsp_board_led_on and then bsp_board_led_off, which will call nrf_gpio_pin_clear and nrf_gpio_pin_set internally.

These are my code:

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
    ret_code_t err_code;

    switch (p_ble_evt->header.evt_id)
    {
    ....
            case BLE_GAP_EVT_SCAN_REQ_REPORT:
            // SCAN_REQ received event.
            bsp_board_led_on(SCANRSP_LED);
            NRF_LOG_INFO("SCAN_REQ");

            ble_gap_evt_scan_req_report_t * p_scan_req_report_t = (ble_gap_evt_scan_req_report_t *)&p_ble_evt->evt.gap_evt.params.scan_req_report;
                  NRF_LOG_INFO("Peer Address = 0x%02x:%02x:%02x:%02x:%02x:%02x",    \
                                p_scan_req_report_t->peer_addr.addr[5],     \
                                p_scan_req_report_t->peer_addr.addr[4],     \
                                p_scan_req_report_t->peer_addr.addr[3],     \
                                p_scan_req_report_t->peer_addr.addr[2],     \
                                p_scan_req_report_t->peer_addr.addr[1],     \
                                p_scan_req_report_t->peer_addr.addr[0]);
                  NRF_LOG_INFO("RSSI value = %d dBm", p_scan_req_report_t->rssi);
            bsp_board_led_off(SCANRSP_LED);
            break;

        default:
            // No implementation needed.
            break;
    }
}

#if MONITOR_RADIO_CRC_MATCH

void SWI3_IRQHandler(void)
{
    bsp_board_led_on(LEDBUTTON_LED);
    /* Clear event register */
    NRF_EGU3->EVENTS_TRIGGERED[0] = 0;
    // NRF_LOG_INFO("Packet received with CRC ok");
    NRF_LOG_INFO("Packet received with CRC error");
    bsp_board_led_off(LEDBUTTON_LED);
}

void monitor_radio_crc_match(void)
{
    /* 6 is the default int. priority used in SDK drivers */
    NVIC_SetPriority(SWI3_IRQn, 6);
    NVIC_EnableIRQ(SWI3_IRQn);

    NRF_EGU3->INTENSET = EGU_INTEN_TRIGGERED0_Msk;

    // NRF_PPI->CH[0].EEP = (uint32_t) &NRF_RADIO->EVENTS_CRCOK;
    NRF_PPI->CH[0].EEP = (uint32_t) &NRF_RADIO->EVENTS_CRCERROR;
    NRF_PPI->CH[0].TEP = (uint32_t) &NRF_EGU3->TASKS_TRIGGER[0];

    NRF_PPI->CHENSET = PPI_CHENSET_CH0_Msk;
}
#endif //MONITOR_RADIO_CRC_MATCH

Thank you,

Toru