Our application stores sensor data in flash and sends the data on request via USB. But if the device is connected to Bluetooth once then it is having issues in USB data transfer. Device receives 21 bytes in place of 20 bytes. Receiving same packet twice even if the host doesn't send. But everything works normal if we power cycle the device.
We wrote application over usbd_ble_uart_pca10056_s140 example.
Thanks,
Vishnu
Which function are you using to output this message? Could you show me the code snippets in which it is outputted.
static void cdc_acm_user_ev_handler(app_usbd_class_inst_t const *p_inst,
app_usbd_cdc_acm_user_event_t event) {
app_usbd_cdc_acm_t const *p_cdc_acm = app_usbd_cdc_acm_class_get(p_inst);
switch (event) {
case APP_USBD_CDC_ACM_USER_EVT_PORT_OPEN: {
/*Set up the first transfer*/
ret_code_t ret = app_usbd_cdc_acm_read(&m_app_cdc_acm,
m_cdc_data_array,
1);
UNUSED_VARIABLE(ret);
msg("CDC ACM port opened");
break;
}
case APP_USBD_CDC_ACM_USER_EVT_PORT_CLOSE:
msg("CDC ACM port closed");
break;
case APP_USBD_CDC_ACM_USER_EVT_TX_DONE:
break;
case APP_USBD_CDC_ACM_USER_EVT_RX_DONE: {
ret_code_t ret;
static uint8_t index = 0;
index++;
do {
if ((m_cdc_data_array[index - 1] == '\n') ||
(m_cdc_data_array[index - 1] == '\r') ||
(index >= (m_ble_nus_max_data_len))) {
if (index > 1) {
msg("USB data received %dbytes", index);
msg_hexdump(m_cdc_data_array, index);
memcpy(usb_receive_buffer, m_cdc_data_array, index);
usb_data_received = true;
}
index = 0;
}
/* Fetch data until internal buffer is empty */
ret = app_usbd_cdc_acm_read(&m_app_cdc_acm,
&m_cdc_data_array[index],
1);
if (ret == NRF_SUCCESS) {
index++;
}
} while (ret == NRF_SUCCESS);
break;
}
default:
break;
}
}
Could you check for me if you have defined NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED 1 in your sdk_config file?
Sorry I am using SDK 15.2. I cannot find this in sdk_config file.
Is the appended CR character what you are referring to when you say unexpected behaviors, or are you observing other unexpected behavior as well?
Well, NO. Actually 21 bytes are seen in the receive buffer. but android is sending only 20 bytes. That is the issue.
My application is, storing the sensor data to a NAND flash and sending this data to android app via USB on request. The data size will be around 200MB-512 MB.
We are doing some packet exchange between android phone and our nRF peripheral before sending the actual data. We are seeing some unexpected packet exchange between the device if we've connected the device via Bluetooth after power up. As soon as the USB cable is plugged in, we are disconnecting Bluetooth for some reasons. After a 3 to 4 USB packets are exchanged without any issues, device is receiving a packet twice, which was supposed to receive only once. After that the communication simply stops. device tries to send data, but android is not getting anything, and feels like some error in packet send from device to android app.
Thus we've debugged and found that if we do not connect to our device using bluetooth after power up, the USB data transfer works smoothly. We are receiving only 20 bytes when android sends 20 bytes of request.
But if we connect bluetooth at any point of time after the power up, the issue arises.
It sounds strange that this only happens when connected to BLE, or if you have not power cycled the device. Perhaps this is related to your call to nrf_drv_clock_lfclk_request, which is superseded when the SoftDevice is enabled.
Can I remove nrf_drv_clock_lfclk_request for our application? it is not called in usbd_ble_app_uart example code. but we are using RTC module in addition to example code.?
Could you attempt to send the same test string with and without enabling the SoftDevice?
That will work. Because we are not connecting bluetooth, It works well if the device was not connected to bluetooth.
Thanks & best regards,
Vishnu Pradeep
Hello Vishnu Pradeep,
Sorry for my late reply.
Vishnu Pradeep said:Sorry I am using SDK 15.2. I cannot find this in sdk_config file.
Vishnu Pradeep said:Well, NO. Actually 21 bytes are seen in the receive buffer. but android is sending only 20 bytes. That is the issue.
Thank you for clarifying.
Vishnu Pradeep said:As soon as the USB cable is plugged in, we are disconnecting Bluetooth for some reasons.
Could you make sure that the device is not in fact resetting, when you connect the USB cable?
Depending on how you have configured your POWER sources, this might be the case.
Vishnu Pradeep said:After a 3 to 4 USB packets are exchanged without any issues, device is receiving a packet twice, which was supposed to receive only once.
Vishnu Pradeep said:After that the communication simply stops. device tries to send data, but android is not getting anything, and feels like some error in packet send from device to android app.
This sounds very strange indeed. Are you familiar with the nRF Sniffer tool? It would be very helpful if you could provide a trace of the BLE communication when this happens, along with a log file of the USB traffic.
Vishnu Pradeep said:But if we connect bluetooth at any point of time after the power up, the issue arises.
This would also be great to see happen in a sniffer trace + usb communication log.
Vishnu Pradeep said:Can I remove nrf_drv_clock_lfclk_request
My mistake there, it seems I misread the request, instead thinking you were requesting the HF clock. The LF clock should have nothing to do with it.
Looking forward to resolving this issue together!
Best regards,
Karl
Could you make sure that the device is not in fact resetting, when you connect the USB cable?
It is not resetting. We disconnect the Bluetooth and stop advertising too when USB is connected.
Are you familiar with the nRF Sniffer tool? It would be very helpful if you could provide a trace of the BLE communication when this happens, along with a log file of the USB traffic.
Will try to do this. In fact the issue is happening without any Bluetooth packet exchange. I just connected the device to our app or nrf uart app and disconnected.
Best regards,
Vishnu
Hello again Vishnu,
Vishnu Pradeep said:It is not resetting. We disconnect the Bluetooth and stop advertising too when USB is connected.
Vishnu Pradeep said:Will try to do this. In fact the issue is happening without any Bluetooth packet exchange. I just connected the device to our app or nrf uart app and disconnected.
I am sorry, but I am not sure I understand what you mean by this. Are you saying that the issue ( added CR character at the end of a transmission ) appears regardless of BLE connection status?
If so, I do not understand the part in which you say it happens without Bluetooth packet exchange, while also saying you are connected to the device through an app or nRF UART app?
Please bear in mind that empty packets are constantly being exchanged in a connection where no communication is happening on the application layer.
Best regards,
Karl
We disconnect the Bluetooth and stop advertising too when USB is connected.
On USB power detect event, we call sd_ble_gap_disconnect and sd_ble_gap_adv_stop.
Are you saying that the issue ( added CR character at the end of a transmission ) appears regardless of BLE connection status?
I am sorry I meant, the packets send by our application, not the empty packets.