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,  Thank you for your Info.  Understood.  I will get more Info and then ask you.

Regards,

Toru

[ShibuyaT]

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.

[Vidar Berg]

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
    ...

[Felipe1]

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.

[Vidar Berg]

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?