This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

USB CDC ACM Example is not working in interrupt mode

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

 

Parents
  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

Reply
  • 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

Children
No Data
Related