USB Bulk transfers with the app_usbd library

[Casper Kronborg Pedersen]

Hi DevZone,

I want to perform USB bulk transmits to a host device while using the app_usbd library. I am using SDK 15.3 and the s140 soft device is enabled.

I have found the app_usbd_ep_transfer() and app_usbd_ep_handled_transfer() functions in the app_usbd.c file at line 1816 and 1831.

Can I use these directly in my user code and does the library have built in scheduling/handling so I don't run into concurrency issues with the end point I am using?
I have not been able to find information on this in the Nordic info center, and I am having a hard time figuring it out by looking in the library code it self

Br. Casper

[ovrebekk]

Hi Casper

Normally these functions are called in the background by whatever class implementation is running on top. 

Have you looked into using one of the standard classes, such a CDC, rather than using the app_usbd library directly?

I can check with the developer if there are any particular considerations to take when using app_usbd directly. 

Best regards
Torbjørn 

[Casper Kronborg Pedersen]

Hi ovrebekk, (Edit, misspelled name)

Sorry for the very late reply, I have been attending a course that took 100% of my time these past days.

I have not been looking into the SDK implementation of the USB CDC class directly. This is because the research I did on it showed that it works as a Virtual Serial Port. By this I assume that it would be like using UART with and FTDI and the connecting with a terminal program such as Termite or PuTTY. 

The planned use of the USB interface is:
 - Using the USB to send and receive commanding/telemetry between the host PC and the nRF52840 chip.
 - Sending data log files from the FATFS system on the nRF52840 to a host PC as fast as possible, as these can be large.

Have I misunderstood how the CDC works or would it actually work well for my application?

Br. Casper

[ovrebekk]

Hi Casper

There are no pure USB bulk examples in the SDK, that is correct. All the existing examples are for defined USB classes such as HID, MSC and CDC. 

Best regards
Torbjørn

[Casper Kronborg Pedersen]

Hi ovrebekk,

Ok. You mentioned earlier that:
"I can check with the developer if there are any particular considerations to take when using app_usbd directly. "

Would you still do that?

Br. Casper

[ovrebekk]

Hi Casper

Sorry for the late reply. I am currently out in leave and will make sure the case is assigned to someone else. 

Regarding the question there is no problem using app_usbd directly, nor using the nrf_drv_usbd driver directly. 

While there are no simple bulk examples available as mentioned earlier, I did recently write an example showing how to send custom 64 byte HID reports using the nrf_drv_usbd interface only:
https://github.com/too1/nrf52-usbd-custom-hid-ep

Best regards
Torbjørn

[Casper Kronborg Pedersen]

Hi Torbjørn,

Thanks for getting back to me. I will have a look at your example.

Br. Casper

[Casper Kronborg Pedersen]

Hi Torbjørn,

It seems that our use of the driver is very similar. However I am using the "app_usbd_ep_transfer()" to initiate transmits instead of the nrf driver directly.

I have a question regarding some specific behavior while handling EPTRANSFERs:

• In line 957-988 you are handling the NRF_DRV_USBD_EVT_EPTRANSFER event in the usbd_event_handler().

• I have similar code using the APP_USBD_EVT_DRV_EPTRANSFER event instead in the bulk_event_handler().
  Here I am seeing calls to the bulk_event_handler() which I did not initialize with a call to app_usbd_ep_transfer(). I am making sure is directed to EPIN with the NRF_USBD_EPIN_CHECK().  It happens when I connect the device to a host PC.
  • This must mean that somewhere else in the library code USBD transmits are started. Do you know where this might come from?

Assumptions on equal functionality:

- NRF_DRV_USBD_EVT_EPTRANSFER  = APP_USBD_EVT_DRV_EPTRANSFER 
- usbd_event_handler() = bulk_event_handler()
- nrf_drv_usbd_ep_transfer() =  app_usbd_ep_transfer()

[Kenneth]

Hello,

Torbjørn is currently out of office.

I don't know this might come from no, but if you want to setup your own usb class/custom descriptor, I can also recommend looking at the usbd example in the sdk: nRF5_SDK_17.0.2_d674dde/examples/peripheral/usbd

This uses the driver directly, and exposes most low-level usb specific functionality.

Also check out the documentation if you haven't already:
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/lib_usbd.html 

Best regards,
Kenneth

[Casper Kronborg Pedersen]

Hi Kenneth,

Thank you for pointing me to that example.

I have been looking into the example you suggested. It seems that the functionalities I use from the driver are used in the same way. This must mean that something in my application is causing these unexpected event handler calls.

Question:

If I am calling USBD transmits without a host connected is it then possible that they are "stored ready" in the peripheral and then sent as soon as a host is connected? Or maybe in some other way so this behavior is seen?

Br. Casper

[Kenneth]

Casper Kronborg Pedersen said:

If I am calling USBD transmits without a host connected is it then possible that they are "stored ready" in the peripheral and then sent as soon as a host is connected? Or maybe in some other way so this behavior is seen?

It's an interesting question, I guess it's kind of undefined, I suggest to try with a global variable to ensure you don't write to the USBD when it's not connected.

Kenneth

[Casper Kronborg Pedersen]

Thanks Kenneth, that is a good idea.

I am already doing something similar that checks for the presence of a USB VBUS before any transmits can be called.

The scenario that I have arises when the host PC application is not paired with the USB driver on the embedded side when the USB transfer is started.
The result is the embedded side never gets a "TX completed event" (APP_USBD_EVT_DRV_EPTRANSFER) and the driver times out waiting for it. Then as soon as the Host PC application is connected I get the APP_USBD_EVT_DRV_EPTRANSFER event. This then looks like a USBD driver transfer was started elsewhere when in reality it was not.

Of course I could add a "pairing" step to both sides and treat this symptom. But as it is now it is not breaking anything, I would just prefer to not have any unpredicted behavior. But if this is exactly what is happening then I am ok with that. Does it sound plausible to you?