Handling NRF_ERROR_BUSY with app_usbd_cdc_acm_write()

[Den]

Hi all,

I am working with SDK 15.3 (S140 6.10) on ISP1807, which is nRF52840 based. 

For my application I needed a USB dongle which works as BLE Central. It is supposed to receive data from BLE and pass it on to PC via COM Port.

I have merged the suitable examples and created the application. It receives packets of 244 bytes from BLE and stores them in a circular buffer with a size of 2440 bytes.  At every 5th BLE packet, the new_usb_packet is increased by one and 1220 bytes are sent via COM Port in a single frame. Every time a USB packet is sent new_usb_packet  is decreased by one. As long as the algorithm works fine its value changes between 1 and 0.

However it works fine to some point (sometimes for hours, sometimes for couple of minutes) and then gets stuck. I need help to figure out what's wrong. In the main I have the following code.

for (;;)
    {
			while (app_usbd_event_queue_process());

				if(new_usb_packet > 0 && usb_busy == false)
				{
						
						ret_code_t ret = app_usbd_cdc_acm_write(&m_app_cdc_acm, &usb_buffer[index], 1220);
					
						if(ret == NRF_ERROR_BUSY)
						{
							NRF_LOG_INFO("usb_busy = true");
							usb_busy = true;
						}
						else if(ret != NRF_SUCCESS)
						{
							NRF_LOG_INFO("USB ret != NRF_SUCCESS");
						}
						else
						{
							new_usb_packet--;
							update_index();
						}
				}
}

If the write function returns NRF_ERROR_BUSY, usb_busy = true and program does not attempt to send anything before usb_busy = false again. Please see below:

case APP_USBD_CDC_ACM_USER_EVT_TX_DONE:
    NRF_LOG_INFO("usb_busy = false");
    usb_busy = false;

For a while the write function returns nothing but NRF_SUCCESS. However at some point it returns NRF_ERROR_BUSY and wait for APP_USBD_CDC_ACM_USER_EVT_TX_DONE event couple of times and then APP_USBD_CDC_ACM_USER_EVT_TX_DONE event never occurs again so the code gets stuck. It keep receiving from BLE correctly however does send anything via COM Port since usb_busy = true.This is the output on RTT viewer:

0> <info> app: usb_busy = true

0> <info> app: usb_busy = false

0> <info> app: usb_busy = true

0> <info> app: usb_busy = false

0> <info> app: usb_busy = true

0> <info> app: usb_busy = false

0> <info> app: usb_busy = false

0> <info> app: usb_busy = true

0> <info> app: usb_busy = false

0> <info> app: usb_busy = true

 

usb_busy is not set back to false ever again..

Is there something wrong with my algorithm or am I missing a configuration or something else? Thanks in advance. 

[Sigurd]

Hi,

How is usb_busy declared ? Is it volatile ?

[Den]

Hi Sigurd,

Thanks for your suggestion. It was initially not declared as "volatile", it was just "bool". Now I changed it to "volatile bool" and had the same problem again. 

I had another observation though. Previously the application had run for 6.5 hours without any problems at all. After 6.5 hours I had to use the other USB port on the same computer and when I did so, the mentioned problem occurred. Today I tried the "volatile" keyword and it has worked for a while. When I used the other USB port, the problem has occurred and usb_busy got stuck at true again.

Your suggestion of using the "volatile" keyword makes me think that you do not see anything wrong with the algorithm, is that right? If so, I have to consider that the source (or at least one of the sources) of the problem to be on the computer side. I am using RealTerm on Win7 and the USB driver provided in the SDK is installed. I will give it a try on a different computer with Win10 and if necessary I will write a small Python code to receive the data. This may give me more insight about what's going on.

Some questions about the baudrate; How should I determine it? Should configure it in the code? I set it on RealTerm to 921600. Could baudrate be a potential source of the problem?

Would you have any other suggestions for me? What else could I check either on the computer side or the application side?Any input is more than welcome.

 

Regards,

Denin

[Sigurd]

Den said:

When I used the other USB port, the problem has occurred and usb_busy got stuck at true again.

 Maybe you could add some retry mechanism, if you don't get the APP_USBD_CDC_ACM_USER_EVT_TX_DONE within x seconds. And only update the "new_usb_packet--;" and "update_index();" when you get the APP_USBD_CDC_ACM_USER_EVT_TX_DONE event ?