Using scanning causes program crashes

RE: Using scanning causes program crashes

MapleBay — Tue, 29 Oct 2024 06:03:43 GMT

Thanks, I found the ble function in example. The reason why it was not found last time is that the example may have been changed.

RE: Using scanning causes program crashes

MapleBay — Tue, 29 Oct 2024 02:11:31 GMT

I once tried to use the C language of pc-ble-driver to write a host computer program to drive it, but I found it was not convenient to use. Later, I urgently migrated it to SDK17 and implemented most of the functions. Currently, there is a problem only when searching. If possible, can you help me solve it?

This is my project path :"examples\connectivity\ble_connectivity_raw\pca10059\ser_s140_usb_hci\arm5_no_packs\ble_connectivity_s140_usb_hci_pca10059.uvprojx"
Nordic_SDK_17.zip

RE: Using scanning causes program crashes

Hung Bui — Mon, 28 Oct 2024 12:26:58 GMT

Hi Genfeng,

If you look at the function cdc_acm_user_ev_handler() in main.c you can find that whenever there is enough data on RX or when there is an end of line byte it will call ble_nus_data_send() to send data.

The pc_ble_driver is the code to run on python on PC, so it's different from the code on nRF52. I am not sure why you develop the logic based on pc_ble_driver.

RE: Using scanning causes program crashes

MapleBay — Mon, 28 Oct 2024 05:48:07 GMT

OK，I think i need to read usbd_uart_ble to getting start, my project developed logic is based on pc_ble_driver.

And do you have something about usbd_uart_ble develop document. I read this document, but i can't get it how to use uart to called ble function, in the main.c, i can't it find it call the ble.

RE: Using scanning causes program crashes

Hung Bui — Tue, 22 Oct 2024 08:04:11 GMT

Hi Genfeng,

Please provide your full code, how do you start scanning ? Do you use the nrf_ble_scan module ?
The nrf_ble_scan already take care of restart scanning when you receiving ADV_REPORT.
Please don't use usb_printf_variadic when you have an error with sd_ble_gap_scan_start()
How do you print the log ?
When do you print SD:Scan_Stop ?

Have you tried to test with our example in ble_central folder ? Do you see the same issue ?

RE: Using scanning causes program crashes

MapleBay — Mon, 21 Oct 2024 14:46:02 GMT

void on_adv_report(const ble_gap_evt_t *const p_ble_gap_evt)
{
  uint32_t err_code = 0;
  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);
  // const uint8_t *address = p_ble_gap_evt->params.adv_report.peer_addr.addr;
  // char _temp_str[250];
  // memset(_temp_str, 0, 250);
  // sprintf(_temp_str, "Advertising Report: Device Address: %02x%02x%02x%02x%02x%02x, ", address[5], address[4], address[3], address[2], address[1], address[0]);
  // sprintf(_temp_str + strlen(_temp_str), "Addr Type: 0x%d, ", p_ble_gap_evt->params.adv_report.peer_addr.addr_type);
  // sprintf(_temp_str + strlen(_temp_str), "Addr ID Peer: 0x%d, ", p_ble_gap_evt->params.adv_report.peer_addr.addr_id_peer);
  // sprintf(_temp_str + strlen(_temp_str), "Device Rssi: %d\n", p_ble_gap_evt->params.adv_report.rssi);
  // usb_printf_variadic("%s\r\n", _temp_str);
  // usb_printf_variadic("Advertising Data: %s", p_ble_gap_evt->params.adv_report.data.p_data);
  // memset(mp_data, 0, 255);
  // m_adv_report_buffer.len = BLE_GAP_SCAN_BUFFER_EXTENDED_MIN * sizeof(mp_data);
  // err_code = sd_ble_gap_scan_stop();
  // nrf_delay_us(100000);

  err_code = sd_ble_gap_scan_start(NULL, &m_adv_report_buffer);
  if (err_code != NRF_SUCCESS)
  {
    usb_printf_variadic("Error starting scan. Error code 0x%02X\r\n", err_code);
  }
  else
  {
    // //printf("Scan started\n");
    // usb_printf_variadic("GAP Scan Start\n");
  }
}

Ok, here is my new code, I disabled usb_printf_variadic() as you said, but the problem still exists.

[22:43:04.034]收←◆<info> app: uart Rx_data:>SD:Scan_Start

[22:43:04.092]收←◆<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29

[22:43:04.155]收←◆<info> app: Received BLE event: 29

[22:43:04.186]收←◆<info> app: Received BLE event: 29
<info> app: Received BLE event: 29

[22:43:04.262]收←◆<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29

[22:43:04.299]收←◆<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29

[22:43:04.388]收←◆<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29

[22:43:04.462]收←◆<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29

[22:43:04.492]收←◆<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29

[22:43:04.555]收←◆<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29

[22:43:04.595]收←◆<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29
<info> app: Received BLE event: 29

[22:43:04.657]收←◆<info> app: Received BLE event: 29
<info> app: Received BLE event: 29

[22:43:06.864]收←◆<info> app: uart Rx_data:>SD:Scan_Stop

RE: Using scanning causes program crashes

Hung Bui — Mon, 21 Oct 2024 07:46:40 GMT

Hi Genfeng,

How often do you see the issue ?
I suspect that there could be a problem of the functions you call in the on_adv_report(). The context level of the event handler is at Softdevice low (level 4)

There could be a chance that calling usb_printf_variadic() inside that context causing a problem. Please try to comment out usb_printf_variadic() and test printing out log on UART or RTT (or use GPIO) to see if you still see the problem.
If usb_printf_variadic() actually a problem, you can consider using a semaphore or use software interrupt to reduce the context to main for example, before calling the funtion.