52832 works different outside of JLink Debugger

[rolandash]

Hi,

This is a really weird problem. 

======================

Setup of 52832 hardware:

- Custom board, using 32MHz XTAL and LF RC.

- SDK15.2, S132 610

- Segger RTT client with JLink debugger.

=======================

This 52832 hardware mainly acts as peripheral and been worked quite well, can connect and communication correctly with iPhone/iPad. 

Recently I try to use a 52840 instead of iPhone/iPad as central to connect with this 52832. The connection parameters are as in below's log.

info> app: [Central Scanning] updating neighbour list: 1 neighbour nodes ...
<info> app: [Central Scanning] connect to peer 0 ......
<info> app: CENTRAL: Connected, handle: 0.
<info> app: CENTRAL: init db discovery: 0.
<debug> ble_db_disc: Starting discovery of service with UUID 0x1 on connection handle 0x0.
<info> app: CENTRAL: start discovery: 0.
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 224 bytes on connection 0x0.
<debug> nrf_ble_gatt: sd_ble_gattc_exchange_mtu_request() on connection 0x0 returned busy, will retry.
<debug> nrf_ble_gatt: Updating data length to 224 on connection 0x0.
<debug> nrf_ble_gatt: Peer on connection 0x0 requested an ATT MTU of 127 bytes.
<debug> nrf_ble_gatt: Updating ATT MTU to 127 bytes (desired: 224) on connection 0x0.
<debug> ble_db_disc: Found service UUID 0x1.
<debug> nrf_ble_gatt: Data length updated to 127 on connection 0x0.
<debug> nrf_ble_gatt: max_rx_octets: 127
<debug> nrf_ble_gatt: max_tx_octets: 127
<debug> nrf_ble_gatt: max_rx_time: 1989
<debug> nrf_ble_gatt: max_tx_time: 1989

In this setup 52832 will send HVX notification to 840, and I am expecting to see maximum 127 bytes of messages received on 840 side.

However, I found that part of the notifications that 52832 send to 52840 are wrong(sometimes even leads to connection timeout), and this problem only occur when 52832 is not connected with JLink Debugger, When I try to investigated it with JLink debugger attached, the problem does not show up.

This seems like some potential memory conflicts with RTT backend to me, probably because I missed something somewhere, or maybe some issue with RTT itself. But the point is I have no means to debug this problem in this case, any suggestion about this situation?

Thank you.

[Kenneth]

Hello,

What have you set NRF_SDH_CLOCK_LF_ACCURACY to on the peripheral/central? Can you try to set it to '1'.

Does you system_nrf52.c file contain errata_108()?

Best regards,
Kenneth

[rolandash]

I suspected clock accuracy issue at first when encounter this problem. But when I check deep into it more, I realized that the physical layer of communication actually works properly on both side. So far I can isolate the cause of this issue within the side of 52832.

I specially checked the memory that sd_ble_gatts_hvx() function referred to, and it seems when JLink debugger is removed, 

sd_ble_gatts_hvx used a very different memory other than I fed it, that explained why 840 received unexpected data as the sender just fetch data from wrong location. But I can not track it down why this could happen because once JLink debugger attached, this problem does not occur.

[rolandash]

Kenneth

Thanks for the hint. However, that did not explain why 840 connect 832 for then 2nd time without my explicit command.

I paste part of my code so you can also have an investigation:

static void ble_central_scan_evt_handler(scan_evt_t const * p_scan_evt)
{
    ret_code_t err_code;
    switch(p_scan_evt->scan_evt_id)
    {
        case NRF_BLE_SCAN_EVT_WHITELIST_REQUEST:
        {
            //on_whitelist_req();
            //m_whitelist_disabled = false;
        } break;
            
        case NRF_BLE_SCAN_EVT_CONNECTING_ERROR:
        {
            err_code = p_scan_evt->params.connecting_err.err_code;
            APP_ERROR_CHECK(err_code);
        } break;
            
        case NRF_BLE_SCAN_EVT_SCAN_TIMEOUT:
        {
            NRF_LOG_INFO("Scan timed out.");
            //scan_start();
        } break;
            
        case NRF_BLE_SCAN_EVT_FILTER_MATCH:
        {
            const ble_gap_evt_adv_report_t* adv_report = p_scan_evt->params.filter_match.p_adv_report;
            dt_phy_update_neighbour_list(adv_report, p_scan_evt);
        }
          break;
        .....
    }
}

.....

static void dt_phy_update_neighbour_list(ble_gap_evt_adv_report_t const * p_adv_report, scan_evt_t const * p_scan_evt)
{
    ......
    ret_code_t err_code = sd_ble_gap_connect(peer_addr,
                                  p_scan_evt->p_scan_params,
                                  &m_scan.conn_params,
                                  1/*APP_BLE_CENTRAL_CONN_CFG_TAG*/);

    ......

}

As you can see that sd_ble_gap_connect() is called only when NRF_BLE_SCAN_EVT_FILTER_MATCH

happen. 

According to nordic SDK document, central will stop scan after sd_ble_gap_connect() is called. So even peripheral is advertising, central should not scanning, so that NRF_BLE_SCAN_EVT_FILTER_MATCH should never happen for 2nd time, unless I explicitly start scanning again. 

The only explanation is sd_ble_gap_connect() does not stop scanning as document stated.

 

[Kenneth]

Do you call scan_stop() before calling sd_ble_gap_connect()? What timeout value do you use in sd_ble_gap_connect()?

Best regards,
Kenneth

[rolandash]

NO, I did not. As in document stated, calling sd_ble_gap_connect() will stop scan activity, so I should not need to duplicate the work.

I did not set scan params except connect_if_match to false. So I think the timeout value of scan is 0 (unlimited time)? sd_ble_gap_connect() should stop it anyway.

    ret_code_t          err_code;
    nrf_ble_scan_init_t init_scan;
    
    memset(&init_scan, 0, sizeof(init_scan));
    
    init_scan.connect_if_match = false;
    init_scan.conn_cfg_tag     = APP_BLE_CENTRAL_CONN_CFG_TAG;

 

[Kenneth]

It can be a bug in the documentation, if you can't find the code is calling scan_stop() explicit then you will need to stop it. '0' means unlimited time yes. My suggestion is as a debugging step to try to call it and see if that occurs.

Best regards,
Kenneth

[rolandash]

thanks Kenneth I will try.