USB CDC ACM Example is not working in interrupt mode

[Deepa Gopinath]

Hi,

On Nordic SDk 15.0, I have observed that USB CDC ACM Example is not working in interrupt mode on nrf52840 Evaluation kit.

But I have tested USB CDC ACM Example in interrupt mode on Nordic SDK 14.2 and its works fine.

To enable interrupt mode, I have modified the USB CDC ACM example of Nordic SDK 14.2 as stated in this link - 

https://devzone.nordicsemi.com/f/nordic-q-a/29641/pca10056-usb-cdc-demo-no-polling

Can you please help us to resolve the issue on Nordic SDK 15.0?

Thanks in Advance

Regards,

Deepa

 

[ovrebekk]

Hi Deepa

All you should have to do to make event handling interrupt driven in SDK v15 is to set APP_USBD_CONFIG_EVENT_QUEUE_ENABLE to 0 in sdk_config.h, and comment out the call to app_usbd_event_queue_process() in main.c

Please try it out, and let me know if you have any issues with it. 

Best regards
Torbjørn

[Deepa Gopinath]

Hi Torbjorn,

With these suggested changes, USB CDC ACM Example is not working in interrupt mode.
Thank you for timely help.

I have one more issue with USB CDC read functionality.
I was unable to get APP_USBD_CDC_ACM_USER_EVT_RX_DONE / PP_USBD_CDC_ACM_USER_EVT_PORT_OPEN events when I send commands to USB port using QT Application.

But after running the application, If I do a dummy open and close of Teraterm connecting to USB port(Say "com14") then I was able to get APP_USBD_CDC_ACM_USER_EVT_RX_DONE / APP_USBD_CDC_ACM_USER_EVT_PORT_OPEN events when I send commands to USB port using QT Application.

Why there is a dependency on dummy open and close of Teraterm connecting to USB port(Say "com14")?
Can I avoid this dependency?

Thanks in Advance

Regards,
Deepa

[Deepa Gopinath]

Hi Torbjorn,

Thanks for the update. I will check this whether we can able to add this changes in QT application.

As stated earlier, without above stated changes, the QT application works fine with STM USB CDC Device. So it will be good if we have a fix in Nordic Application end instead of C# application.

Can you please help us to provide a fix at Nordic USB CDC application end?

Thanks in Advance!!

Regards,

Deepa

[ovrebekk]

Hi 

I tried to make some changes to the driver to make this work. 

I got it to respond without requiring DTR to be set, but the data coming in looks corrupted. 

I will have to do some more testing and get back to you.

Best regards
Torbjørn

[Deepa Gopinath]

Hi Torbjorn,

Thanks for the update. I will be waiting for the solution from the USB CDC Driver End.

Regards,

Deepa

[ovrebekk]

Hi 

Unfortunately I didn't get a lot of time to look into this, and now I am leaving for vacation.

The changes I did make can be found in this attached file.  

Essentially you would have to make some changes to the handling of the APP_USBD_CDC_REQ_SET_CONTROL_LINE_STATE case in the setup_req_class_out(..) function,  and also change any code that checks the dtr_state, similar to what I tried to do in the app_usbd_cdc_acm_write function. 

Best regards
Torbjørn

[Alec]

Hi Torbjørn,

I'm actually working on the same project, we migrated it to the SDK 16.0.0 and put it a bit separately to simplify further SDK updates.

So previously I was not too happy with the idea of patching the USB driver, but it was acceptable (and your solution is working fine, thanks).

Now this patching is not an option - I'm looking for the ways to ignore the virtual DTR line without changing the driver/library source files.

Can you help us with it? Maybe some SDK options or user-defined callback functions?

Thanks,

Alec

[ovrebekk]

Hi Alec

The implementation of the DTR line hasn't really changed much since the older SDK's, so the same limitations apply. 

I don't see any way to change this behaviour without having to change the app_usbd_cdc_acm.c implementation. 

I could check with the developer again if he has some pointers, but unfortunately he is out in vacation for the next couple of weeks so I will have to wait until he returns. 

Best regards
Torbjørn

[Alec]

Hello Torbjørn,

Any updates?

WBR Alec

[ovrebekk]

Hi Alec

My apologies, I forgot to get back to you. 

I discussed this with the developer but he agreed with my assessment. By design the DTR signal is controlled exclusively by the driver itself, and there is no way to access this from the application without changing the driver. 

At a minimum you would need to make the functions controlling the DTR signal present in the header file, so that you can access them from the application and simulate a line state update from the host. 

Best regards
Torbjørn