Scanner freezes application without debugger connected on SD 6.0.0

[Martin]

Hello

The scanner causes the code to freeze when a debugger is not connected.

We are developing a system where one of our units is to run on the nRF52832. During development of the application we ran in to a problem after porting to SDK15 from 14.2 (and also from SoftDevice 5.0.0 to 6.0.0.
We are advertising and scanning for advertising packet data in intervals less than a second, every five seconds. With the new SoftDevice API, and the possibility for longer advertising packets we need to "continue" the scanner after recieving an advertisement packet using sd_ble_gap_scan_start(NULL, adv_report_buffer). This is done by the ble_event_handler as shown below:

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
    ret_code_t            err_code = 0;
    ble_gap_evt_t const * p_gap_evt = &p_ble_evt->evt.gap_evt;

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_ADV_REPORT:
        {
            adv_parse(&p_gap_evt->params.adv_report);
            sd_ble_gap_scan_start(NULL,&m_scan_buffer);
            APP_ERROR_CHECK(err_code);
             
        }break; // BLE_GAP_EVT_ADV_REPORT
        
       case BLE_GAP_EVT_TIMEOUT:
       {
           if (p_gap_evt->params.timeout.src == BLE_GAP_TIMEOUT_SRC_SCAN)
           {
              sd_ble_gap_scan_stop();
              APP_ERROR_CHECK(err_code);
           }           
       } break;
        default:
            break;
    }
}

This event also calls the advertising packet parser, which copies the advertisement data into a new variable from the buffer before parsing it. 

The code runs fine on PCA10040 DK while the internal or an external jlink debugger is connected to Segger Embedded Studio.

When we disconnect the debugger the code freezes within 30 seconds.

We have tried commenting out all instances which starts the scanner, and this leads to the advertiser and the rest of the code is working fine with or without a debugger connected.

This leads us to believe the scanner is the problem. We have diagnosed the problem using the Power Profiler, both externally and as a shield on the DK with the code.

While the debugger is connected it looks like this:

While if we disconnect the debugger it looks like this:

For the ones not familliar with the PPK, it will use less power when not connected do a debugger which is why the base line is lower on the second picture. 

At the time where you can see the power peak and stay high the DK stops responding to its application and does not send any more advertising packets.

Any idea what this could be?

[Martin]

I was able to resolve this issue by setting RTT config mode:

// <o> SEGGER_RTT_CONFIG_DEFAULT_MODE  - RTT behavior if the buffer is full.
 

// <i> The following modes are supported:
// <i> - SKIP  - Do not block, output nothing.
// <i> - TRIM  - Do not block, output as much as fits.
// <i> - BLOCK - Wait until there is space in the buffer.
// <0=> SKIP 
// <1=> TRIM 
// <2=> BLOCK_IF_FIFO_FULL 

#ifndef SEGGER_RTT_CONFIG_DEFAULT_MODE
#define SEGGER_RTT_CONFIG_DEFAULT_MODE 1
#endif

The problem was we had this in block, after some troubleshooting on our own hardware. This caused the chip to halt.