USBD issue after bluetooth is connected once

[Vishnu Pradeep]

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 

[Karl Ylvisaker]

Hello Vishnu,

We wrote application over usbd_ble_uart_pca10056_s140 example. 

But if the device is connected to Bluetooth once then it is having issues in USB data transfer.

Please elaborate on which modifications you have done to the example. Did you test an unmodified version of the example as detailed in the USBD BLE UART example documentation section Setup and Testing? Did the unmodified example behaves as detailed in the documentation?

The example demonstrates how the device can receive information through the UART service, and relay it to the usbd cdc acm module.

Device receives 21 bytes in place of 20 bytes.

Could you verify for me that you are not in fact queueing 21 bytes for sending, such as if you are sending a \0 terminated c-string?

Is there any error messages being generated / outputted to your logger module?
Please make sure that DEBUG is defined in your preprocessor defines, as shown in the included image.



Looking forward to resolving this issue together!

Best regards,
Karl

[Vishnu Pradeep]

This is my initialization sequence

    timers_init();
    ret_code_t err_code = nrf_drv_clock_init();                        //Initialize the clock source specified in the nrf_drv_config.h file, i.e. the CLOCK_CONFIG_LF_SRC constant
    APP_ERROR_CHECK(err_code);
    nrf_drv_clock_lfclk_request(NULL);
   //Initialize RTC instance
   nrf_drv_rtc_config_t config = NRF_DRV_RTC_DEFAULT_CONFIG;
   config.prescaler = 4095;
   err_code = nrf_drv_rtc_init(&rtc, &config, rtc_handler);
   APP_ERROR_CHECK(err_code);

   err_code = nrf_drv_rtc_cc_set(&rtc, 0, RTC_CC_VALUE, true); //Set RTC compare value to trigger interrupt. Configure the interrupt frequency by adjust RTC_CC_VALUE and RTC_FREQUENCY constant in top of main.c
   APP_ERROR_CHECK(err_code);

   //Power on RTC instance
   nrf_drv_rtc_enable(&rtc);
/* Register first to receive an event when initialization is complete. */
    (void) fds_register(fds_evt_handler);

    msg("Initializing fds...");

    ret_code_t rc = fds_init();
    APP_ERROR_CHECK(rc);

    /* Wait for fds to initialize. */
    wait_for_fds_ready();
    get_fds_stat();
     static const app_usbd_config_t usbd_config = {
      .ev_state_proc = usbd_user_ev_handler};

  app_usbd_serial_num_generate();
  ret = app_usbd_init(&usbd_config);
  APP_ERROR_CHECK(ret);

  app_usbd_class_inst_t const *class_cdc_acm = app_usbd_cdc_acm_class_inst_get(&m_app_cdc_acm);
  ret = app_usbd_class_append(class_cdc_acm);
  APP_ERROR_CHECK(ret);
  ret = app_usbd_power_events_enable();
  APP_ERROR_CHECK(ret);

Edit: Yes it is behaving the same with example code. Power on the device -> connect Bluetooth -> disconnect -> send data via USB, 21 bytes.
If I power cycle and send data without connecting the Bluetooth, receives 20 bytes

[Karl Ylvisaker]

Hello again Vishnu,

Vishnu Pradeep said:

This is my initialization sequence

This does not tell me much, unfortunately. I can only say that your app_usbd initialization looks all right to me.

Karl Ylvisaker said:

Is there any error messages being generated / outputted to your logger module?
Please make sure that DEBUG is defined in your preprocessor defines, as shown in the included image.

Please confirm whether you have done this, and what you are seeing.
What does the logger output when you establish the first connection? Is there any error message generated when the unexpected byte is sent?

Vishnu Pradeep said:

Edit: Yes it is behaving the same with example code. Power on the device -> connect Bluetooth -> disconnect -> send data via USB, 21 bytes.
If I power cycle and send data without connecting the Bluetooth, receives 20 bytes

Could you tell me specifically which data is being sent here? What is the contents of the unexpected byte? 

Best regards,
Karl

[Vishnu Pradeep]

Karl Ylvisaker said:

Please confirm whether you have done this, and what you are seeing.

yes, I've added DEBUG. Not seeing any error message generated as such in debug log. 

Karl Ylvisaker said:

Is there any error message generated when the unexpected byte is sent?

No. 

Karl Ylvisaker said:

Could you tell me specifically which data is being sent here? What is the contents of the unexpected byte? 

I was sending 20 bytes. BRK0000000000000000Z. But received 21 bytes with 0x0D at the end. This is not happening if we are sending data via USB after power cycle and not connecting to Bluetooth. If the device gets connected to Bluetooth once after power on, USB data transfer is having some unexpected behaviors. If we don't connect to Bluetooth and start USB data transfer after power up, it works fine.

Actually we are sending data to android phone over OTG. Whenever the device is connected to any nRF uart app even on a different phone, this issue happens.

[Karl Ylvisaker]

Hello,

Vishnu Pradeep said:

yes, I've added DEBUG. Not seeing any error message generated as such in debug log.

Thank you for verifying this.

Vishnu Pradeep said:

I was sending 20 bytes. BRK0000000000000000Z. But received 21 bytes with 0x0D at the end.

It seems a Carriage Return character is appended to the end of your message. 
Which function are you using to output this message? Could you show me the code snippets in which it is outputted.

Could you check for me if you have defined NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED 1 in your sdk_config file?
This will automatically append CR for each Line Feed character. 

Vishnu Pradeep said:

This is not happening if we are sending data via USB after power cycle and not connecting to Bluetooth. If the device gets connected to Bluetooth once after power on, USB data transfer is having some unexpected behaviors. If we don't connect to Bluetooth and start USB data transfer after power up, it works fine.

Is the appended CR character what you are referring to when you say unexpected behaviors, or are you observing other unexpected behavior as well?
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.
Could you attempt to send the same test string with and without enabling the SoftDevice?

Looking forward to resolving this issue together!

Best regards,
Karl