SCAN_REQ and SCAN_RSP logging

RE: SCAN_REQ and SCAN_RSP logging

Felipe1 — Mon, 19 Dec 2022 08:40:32 GMT

Hi Vidar,

Thank you for your comments and I am grateful for your support.

Best Regards,

Toru

RE: SCAN_REQ and SCAN_RSP logging

Vidar Berg — Mon, 19 Dec 2022 08:13:21 GMT

Hi Toru,

Yes, everything appears to be as expected now.

RE: SCAN_REQ and SCAN_RSP logging

Felipe1 — Sun, 18 Dec 2022 00:26:10 GMT

Hi Vidar,

I retested it using nrf_gpio_pin_toggle() for mapping BLE_GAP_EVT_SCAN_REQ_REPORT into channel 0 and CRC error into channel 1.

In my testing, the following 3 patterns were recorded.

1. BLE_GAP_EVT_SCAN_REQ_REPORT (SCAN_REQ is received and then SCAN_RSP is sent)

2. CRC error (Received packet is discarded due to CRC error)

3. No packet is received

Besides these, there were 2 more patterns.

4. SCAN_REQ is received for the 1st ADV_IND, and the SCAN_RSP is sent. One packet is received after SCAN_RSP, and then CRC error occurs.

5. One packet is received after the 1st ADV_IND and then CRC error occurs. SCAN_REQ is received after the 3rd ADV_IND and then SCAN_RSP is sent.

Seeing the above, the wave patterns are categorized by these cases, and each case can be explained as a normal behavior. If it makes sense, I will close this discussion. Thank you. -Toru

RE: SCAN_REQ and SCAN_RSP logging

Felipe1 — Mon, 28 Nov 2022 23:28:54 GMT

Hi Vidar,

For the quick testing, the above pattern 1 and 2 waveforms have been changed by setting NRF_LOG_ENABLED to '0' in sdk_config.h. The ~8mA current part has gone. I will go through the data and check if there are any other patterns like 4.

Thank you,

Toru

RE: SCAN_REQ and SCAN_RSP logging

Felipe1 — Mon, 28 Nov 2022 08:44:51 GMT

Hi Vidar,

Thank you for your comments. I will follow your advice and let you know the result.

Thank you,

Toru

RE: SCAN_REQ and SCAN_RSP logging

Vidar Berg — Mon, 28 Nov 2022 08:33:12 GMT

Hi Toru,

Thanks for confirming. This means the CPU is executing code from the application and not in the Softdevice when the outputs are toggled.

If you haven't already, please comment out the leds_init() and buttons_init() calls in main() and turn off logging by setting NRF_LOG_ENABLED to '0' in sdk_config.h. The LED indication relies on app timer interrupts to toggle the output, so that might be what we are seeing in the waveform. That, or it could be an UART interrupt from the log processing.

Vidar

RE: SCAN_REQ and SCAN_RSP logging

Felipe1 — Sat, 26 Nov 2022 02:16:49 GMT

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

RE: SCAN_REQ and SCAN_RSP logging

Vidar Berg — Fri, 25 Nov 2022 09:48:03 GMT

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?

RE: SCAN_REQ and SCAN_RSP logging

Felipe1 — Fri, 25 Nov 2022 06:22:30 GMT

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

RE: SCAN_REQ and SCAN_RSP logging

Vidar Berg — Thu, 24 Nov 2022 14:05:58 GMT

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

RE: SCAN_REQ and SCAN_RSP logging

Felipe1 — Wed, 23 Nov 2022 08:42:48 GMT

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

RE: SCAN_REQ and SCAN_RSP logging

Vidar Berg — Fri, 19 Aug 2022 06:22:35 GMT

Hi,

The CRC will only be computed if you receive the whole packet first. So it may also be that the RADIO is not receiving the preamble for the scan request and therefore not checking the crc either. Do you have a shielded room our enclosure you could test your device in to eliminate noise or interference from other devices?

RE: SCAN_REQ and SCAN_RSP logging

Felipe1 — Wed, 17 Aug 2022 23:46:09 GMT

Hi Vidar,

Thank you for your suggestion. I tested it in my environment and it shows CRC match messages like this :

[00:00:00.000,000] <info> app: Packet received with CRC ok
[00:00:00.000,000] <info> app: SCAN_REQ
[00:00:00.000,000] <info> app: Peer Address = 0x6A:C1:0E:B3:30:36
[00:00:00.000,000] <info> app: RSSI value = -56 dBm
[00:00:00.000,000] <info> app: Packet received with CRC ok
[00:00:00.000,000] <info> app: SCAN_REQ
[00:00:00.000,000] <info> app: Peer Address = 0x6A:C1:0E:B3:30:36
[00:00:00.000,000] <info> app: RSSI value = -56 dBm

(Please ignore the timestamp)

But how can I find the CRC mismatch? Should I tried to use "&NRF_RADIO->EVENTS_CRCERROR" instead?

I tried it but I have not seen the repro yet.

RE: SCAN_REQ and SCAN_RSP logging

Vidar Berg — Wed, 17 Aug 2022 07:23:04 GMT

Hi,

Based on the DRGN-15484 description, I would only expect reception to potentially improve in v7.3.0 if you are advertising with a timeout. I still believe the most likely explanation to the missed response is that the scan request failed to be received by the nRF. To confirm this, you could try to monitor the RADIO crc match event (EVENTS_CRCOK) as done in the snippet below.

#define MONITOR_RADIO_CRC_MATCH 1

#if MONITOR_RADIO_CRC_MATCH

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

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].TEP = (uint32_t) &NRF_EGU3->TASKS_TRIGGER[0];

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


/**@brief Application main function.
 */
int main(void)
{
    ...
    ble_stack_init();
#if MONITOR_RADIO_CRC_MATCH
    monitor_radio_crc_match();
#endif //MONITOR_RADIO_CRC_MATCH
    ...

RE: SCAN_REQ and SCAN_RSP logging

ShibuyaT — Wed, 17 Aug 2022 06:20:46 GMT

Hi Vidar

Thank you for reply.

I am colleague of Toru. I asked him to contact you.

I took two images about this phenomenon.

There are snapshots of power consumption wave form.

X axis is time(ms) and Y axis power consumption(mA)

AS you can see, OK file shows Advertise->SCAN_REQ->SCAN_RSEP.

On the other hand, NG file show Advertise->SCAN_REQ.

Our nRF52832 does not respond SCAN_RSEP.

Advertise interval is 40ms.

The phenomenon is happened about once or twice per 1second.

First I used softdevice version 7.0.1.

Then we found s132_nrf52_7.3.0 improve missing scan request reception.

So we update softdevice from 7.0.1 to 7.3.0.

However the result is the same.

Do you have any suggestion?

For example I might miss some improvement information/errata,

or I can get debug? how to debug?

If you can indicate me to put some debug coed and help you to analyze, please let me know.

RE: SCAN_REQ and SCAN_RSP logging

Felipe1 — Mon, 15 Aug 2022 08:32:03 GMT

Hi Vidar, Thank you for your Info. Understood. I will get more Info and then ask you.

Regards,

Toru

RE: SCAN_REQ and SCAN_RSP logging

Vidar Berg — Mon, 15 Aug 2022 07:58:38 GMT

Hi Toru,

Thanks for making me aware of this bug. Based on the bug description, this should only occur on the last adv. event if you are advertising with a timeout, so I'm not sure if it is relevant to your case.

RE: SCAN_REQ and SCAN_RSP logging

Felipe1 — Sat, 13 Aug 2022 07:44:05 GMT

Hi Vidar,

Thank you for your comments. As you wrote, the sniffer Info cannot exclude those possibilities. Therefore I was trying to look into the device itself. (Softdevice should work as expected, but seeing the release note of v7.3.0, DRGN-15484 would be related to SCAN_RSP.)

But I will stop this approach and check it in another way.

Thank you again for your support,

Toru

RE: SCAN_REQ and SCAN_RSP logging

Vidar Berg — Fri, 12 Aug 2022 13:08:28 GMT

Hi Toru,

No problem 🙂 The Softdevice will always send the SCAN_RSP after receiving SCAN_REQ unless there is an undiscovered bug in the stack. I think the more likely explanation is that either 1. the scan request was only received by the sniffer, but not the nRF 2. the sniffer missed the scan response packet.

Regards,

Vidar

RE: SCAN_REQ and SCAN_RSP logging

Felipe1 — Fri, 12 Aug 2022 02:27:35 GMT

Hi Vidar, Thank you so much for your answer.

I understand the first two answers. For the third one, regardless of ACK, I wanted to know the logging mechanism to confirm that Softdevice completes the SCAN_RSP sending procedure.

Seeing a sniffer log below, SCAN_RSP is missing after some of SCAN_REQ packets. But the sniffer might have missed the packet and the peripheral device might have worked well. So, the sniffer log is not helpful. I will collect more Info, and I may ask some more questions related to this.

Regards,

Toru (Felipe1)

RE: SCAN_REQ and SCAN_RSP logging

Vidar Berg — Thu, 11 Aug 2022 13:32:12 GMT

Hello,

[quote user=""]If this event is received, does Softdevice recognize the packet as SCAN_REQ properly and surely send back SCAN_RSP?[/quote]

Yes, that is correct.

[quote user=""]If there are any problems in receiving a SCAN_REQ packet (e.g. CRC error), can I see any logs/messages?[/quote]

You will only receive the event if the scan request was received properly. The same goes for any other BLE packet. Packets with CRC errors are not processed by the stack.

[quote user=""]Or if there are any problems in sending a SCAN_RSP packet, can I see any logs/messages as well?[/quote]

A scan response packet will not be acknowledged by the scanner, so there is no way for the advertiser to know if the response was received or not. In other words, if the scanner failed to receive the scan response, then it will have to send new SCAN_REQ.

Best regards,

Vidar