pc-ble-driver problem : target reset after starting scanning

[KEOPS]

Hi,

We have a Gateway based on mediatek MT7688 MIPS 32bits architecture CPU, and we integrate an nRF523832 chip to acquire BLE packets.

The gateway uses OpenWrt OS, and communicates with the nRF52832 chip over UART using pc-ble-driver in my application.

I am using pc-ble-driver-connectivity-V4.1.1.

My problem is : in order to test the pc-ble-driver on the gatewen, i used the heart rate collector example, and when i start scanning, it is fine, i acquire packets (ble address, rssi, channel id ...etc), but after a while, the scan stops suddenly and i have these messages : "Status: 6, message: Target Reset performed , Status: 7, message: Connection active" .

i tried many times but the result is the same, the target restarts suddenly !

And the time between the application start and the target reset is completely random ! (20 seconds, 45 seconds , 10 seconds)

See the attached image for more details.

Any one have an idea why the target restarts suddenly ?

Thanks,

[Edvin]

Hello,

The line: "Failed to receive response for command"

comes from serialization_transport.cpp, from the SerializationTransport::send() function. It is the NRF_ERROR_SD_RPC_SERIALIZATION_TRANSPORT_NO_RESPONSE return value (0x8016) that is returned. 

"Error sending packet to target. Code:" is printed from encode_decode() in ble_common.cpp. 

The reason why this happens is not easy to say. It means that the nRF has stopped responding. How did you program the device, and with what?

It looks like the application is trying to reset the nRF, but that it isn't able to do so. Did you connect the reset pin to your controller? And did you shorten SB 17 on the DK? The log doesn't say why it attempts to reset the device, though. Can you try to set a breakpoint on the line saying "Target Reset performed", and see if you can see from the callstack why this is called?

Best regards,

Edvin

[KEOPS]

Hello,

Thanks for reply,

• The application turns in the gateway (MT7688 MIPS 32bits architecture CPU) with OpenWrt OS.
• I have programmed the nrf52832 chip with connectivity_4.0.0_1m_with_s132_6.1.0.hex which is present in the git repository.
• the nrf52832 is not a DK but it is in the gateway on the same PCB as the MT7688 MIPS 32bits architecture CPU (see attached images).
• I used the heart_rate_collector example in the pc-ble-driver repository.

unfortunately, i cannot debug on the gateway for the moment, it is very difficult (if no choice, i will try with gdb server on remote !!)

Do you think that my problem is that the pc-ble-driver is not compatible with embedded architectures ? or...

Best regards,

[Edvin]

Can you see whether you are able to reproduce it using a DK so that you have debugging capabilities? I believe development would be a bit easier if you are able to debug.

[KEOPS]

With exactly the same application (same code heart_rate_collector and same pc-ble-driver) on my pc (ubuntu 18.04 LTS) and nRF52, i don't have the problem, now it's been 3 hours since the application runs and no problem !!

I don't understand why it crashes in the gateway after few sencods!!

Thanks,

[Edvin]

Me neither.

What are the differences between the DK and your PCB? Do you use the same crystals? Do you have a Low frequency Xtal? The 32KHz? Although if you are able to scan that doesn't seem like the issue, but I am just trying to think of possible reasons. 

And again, can you try to set a breakpoint on the line where it says: "Status 6, message: Target reset performed", and see if you can determine from the callstack why this happens? What caused the device to try to reset the nRF?

[KEOPS]

finally, i can debug on the gateway now 

attached the callstack.

Do you see something interesting ?

Edit : i have a remark :

when i add a usleep(50000) just before sd_ble_gap_scan_start() on on_adv_report() it seems like the reset time before reset is bigger > 4 min

static void on_adv_report(const ble_gap_evt_t * const p_ble_gap_evt)
{
    uint32_t err_code;
    uint8_t  str[STRING_BUFFER_SIZE] = {0};

    // Log the Bluetooth device address of advertisement packet received.
    ble_address_to_string_convert(p_ble_gap_evt->params.adv_report.peer_addr, str);
    
    printf("address: 0x%s", str);
    fflush(stdout);
    printf(" - ch_idx : %d ", p_ble_gap_evt->params.adv_report.ch_index);
    fflush(stdout);
    printf(" - rssi : %d \n", p_ble_gap_evt->params.adv_report.rssi);
    fflush(stdout);

    //wait
    usleep(50000);

    err_code = sd_ble_gap_scan_start(m_adapter, NULL, NULL);
    if (err_code != NRF_SUCCESS)
    {
       printf("Scan start failed with error code: 0x%02X\n", err_code);
        fflush(stdout);
    }

}

my supposition : it seems like the problem is sd_ble_gap_scan_start(), the call of this method is very fast and the transport fails !!!

[Edvin]

Hello,

I see that you did some changes to the on_adv_report() function, is that correct? Does it happen if you revert to the standard:

static void on_adv_report(const ble_gap_evt_t * const p_ble_gap_evt)
{
    uint32_t err_code;
    uint8_t  str[STRING_BUFFER_SIZE] = {0};

    // Log the Bluetooth device address of advertisement packet received.
    ble_address_to_string_convert(p_ble_gap_evt->params.adv_report.peer_addr, str);
    printf("Received advertisement report with device address: 0x%s\n", str);
    fflush(stdout);

    if (find_adv_name(&p_ble_gap_evt->params.adv_report, TARGET_DEV_NAME))
    {
        if (m_connected_devices >= MAX_PEER_COUNT || m_connection_is_in_progress)
        {
            return;
        }

        err_code = sd_ble_gap_connect(m_adapter,
                                      &(p_ble_gap_evt->params.adv_report.peer_addr),
                                      &m_scan_param,
                                      &m_connection_param
#if NRF_SD_BLE_API >= 5
                                     , m_config_id
#endif
                                     );
        if (err_code != NRF_SUCCESS)
        {
            printf("Connection Request Failed, reason %d\n", err_code);
            fflush(stdout);
            return;
        }

        m_connection_is_in_progress = true;
    }
#if NRF_SD_BLE_API >= 6
    else {
        err_code = sd_ble_gap_scan_start(m_adapter, NULL, &m_adv_report_buffer);

        if (err_code != NRF_SUCCESS)
        {
            printf("Scan start failed with error code: %d\n", err_code);
            fflush(stdout);
        }
        else
        {
            printf("Scan started\n");
            fflush(stdout);
        }
    }
#endif

}

Not saying that you can't do any changes, but just to pinpoint whether it is the changes or if it is something with the setup. Do you use the same baudrate/frequency as when you use the DK (and it doesn't fail)?

Can you try to stop the debugger inside the sd_ble_gap_scan_start() and see what check or what function that returns the err_code != 0?

[KEOPS]

I have tested the heart_rate_collector as that without any modification, and still have the same problem.

Yes, i used the same baudrate (1m) for both DK and gateway, and it doen't fail in the DK but fails in the gateway

i have stopped the debugger inside the sd_ble_gap_scan_start() but i dont see anything that can help me !!.

FYI: i have tested the heart_rate_collector in connectivity V3 with connectivity_2.0.1_1m_with_s132_5.0.hex and it works fine, no crashes since boot (7 hours)

[Edvin]

Hello,

I need to have someone who has worked a bit closer with serialization to have a look at this. But just to check: When you run on the DK, does it still say "Target Reset performed", but without the errors afterward?