USB throughput for nRF52840

RE: USB throughput for nRF52840

Håkon Alseth — Thu, 30 Apr 2020 07:14:50 GMT

Hi,

[quote user="henryh"]I am using v16[/quote]

That is good.

Do you have performance issues with sizes ending up in a short packet or ZLP?

By looking at usbd.c::usbd_send_data_to_host(), it seems that ZLP isn't handled.

Try implementing something like this when sending:

    else
    {
      // Send data
      usb_tx_xfer.p_data.tx = buff;
      usb_tx_xfer.size = size;

      tx_flag = true;
      /* Check if ZLP flag should be set */
      if ((size > NRF_DRV_USBD_EPSIZE) && (size % NRF_DRV_USBD_EPSIZE == 0)) 
      {
        usb_tx_xfer.flags |= NRFX_USBD_TRANSFER_ZLP_FLAG;
      } else {
        /* ZLP not needed, in case your structure is using global memory and not stacked, we clear the .flags */
        usb_tx_xfer.flags = 0;
      }
      ret_val=nrf_drv_usbd_ep_transfer(NRF_DRV_USBD_EPIN1,&usb_tx_xfer);
    
      ret_val=NRF_SUCCESS;
    }

Kind regards,

Håkon

RE: USB throughput for nRF52840

henryh — Wed, 29 Apr 2020 12:42:08 GMT

I am using v16

RE: USB throughput for nRF52840

Håkon Alseth — Wed, 29 Apr 2020 12:25:54 GMT

Hi,

I'm glad to hear that some of the issues are resolved.

[quote user="henryh"]The delays we have been seeing seem to be related to packets falling on the EP size (ZLP?) and maybe short packets. I noticed that ZLP handling can be enabled using a flag in the transfer data structure. Is this normally enabled? [/quote]

Zero length packets (ZLP) depends on how you send data. If your application sends larger frames, and set the packet size to be bMaxPacketSize=512, but you want to send 1024 bytes of data (1024 modulo 512 = 0), then you send a ZLP at the end to state that the transfer is finished. In the case you send 513 bytes, the next transfer is 1 byte (a short packet), so no ZLP needed in that scenario.

If you send packets that are equal or less than bMaxPacketSize, no ZLP is needed. If larger, then yes, but only sent if size % bMaxPacketSize == 0.

If no ZLP is sent to indicate that the transfer is complete, you'll see a "lag" in the data on the host side, where you get the former data on the current transfer, etc. It will not look as "seamless" as it should be if you are inspecting the data. Example: If you're sending data over CDC (usb serial port) and looking at it, then it looks a bit strange if you send strings with length of 2*bMaxPacketSize without ZLP.

[quote user="henryh"]We also use some Atmel products and noted an improvement in performance when short packet handling was enabled. Is there a related issue with short packets when using the Nordic USB library? [/quote]

Short packets should be handled. Which SDK version are you using?

Kind regards,

Håkon

RE: USB throughput for nRF52840

henryh — Tue, 28 Apr 2020 14:22:26 GMT

This problem has been mostly resolved but there are a couple of questions still. The throughput issue is related to how packet are handled by the test tool and we have had some success in fixing it. On the Nordic side, I was using the nrfx_usbd_ep_transfer() function incorrectly, slicing transfers up instead of just calling the function with a stable transfer buffer and blocking until the transfer completes. In the future I may move this to a handled function to avoid blocking but the simpler implementation will do for now in this application. I have been able to get reasonable transfer times (1.28 MS for 512 byte packets @ 4 MS; the "transfer time" is elapsed time for the stack to go back to idle after calling nrfx_usbd_ep_transfer() ).

The delays we have been seeing seem to be related to packets falling on the EP size (ZLP?) and maybe short packets. I noticed that ZLP handling can be enabled using a flag in the transfer data structure. Is this normally enabled? We also use some Atmel products and noted an improvement in performance when short packet handling was enabled. Is there a related issue with short packets when using the Nordic USB library?

RE: USB throughput for nRF52840

Håkon Alseth — Tue, 28 Apr 2020 14:06:26 GMT

Hi,

Could you share a updated .zip file of your project, including the sdk_config? Is your printf routed to UART (this will increase latency)?

Which SDK version are you using?

Kind regards,

Håkon

RE: USB throughput for nRF52840

henryh — Thu, 23 Apr 2020 21:18:50 GMT

Can you provide some insight into the nrfx_usbd_ep_transfer function? I am trying to run 512 byte data over bulk endpoints at a sustained frame rate (say 5 MS) and am having some trouble. The code is based on your USBD example with modifications to convert to bulk transfers, add EPOUT2 and EPIN1 endpoints and modify the descriptors to identify as a WINUSB (WCID) device. The code connects to the WINUSB driver and correctly responds to manually triggered data but is dropping frames in this sustained testing. My understanding is that the ep_transfer() function accepts any size packet and will packetize it (64 byte packets for bulk) and also attach a zero length packet (ZLP) in this case since the data size is a multiple of the endpoint buffer size. In my code, I transfer the buffer and then wait for the endpoint transfer to complete using nrfx_drv_usbd_ep_is_busy() function before exciting my transfer function. This sequence would seem to make my transfer function block and therefore ensure that the endpoint is ready for another transaction once I have exited to main. The system is behaving like it has a race condition and it is sensitive to the frame time but performance does not improve when extending the frame (even to 100 MS). I am also seeing large delays in the completion time for the USB transfer, up to around 7 MS in some cases. Any suggestions?

RE: USB throughput for nRF52840

Susheel Nuguru — Tue, 21 Apr 2020 13:46:19 GMT

I am not very familiar with this driver, so I am not certain. Could it be that that the call to nrfx_usbd_ep_transfer failed with error and you did not handle it? saying this since your code ignores the return value to the call nrfx_usbd_ep_transfer.

RE: USB throughput for nRF52840

henryh — Mon, 20 Apr 2020 20:44:58 GMT

I am using your USB stack from the USBD example. All I have done is add an EPOUT2 endpoint to the code. I am using nrfx_usbd_ep_transfer() to push 64 bytes into/out of the stack. Can I get some help?

RE: USB throughput for nRF52840

henryh — Mon, 20 Apr 2020 20:42:34 GMT

Can I get some help here?

RE: USB throughput for nRF52840

henryh — Thu, 16 Apr 2020 13:46:47 GMT

I've chosen to build this on the USBD example to avoid uses classes since I have never used them. The examples that use app_usbd are all based on class usage and seem pretty complex as opposed to the USBD example.

RE: USB throughput for nRF52840

Susheel Nuguru — Thu, 16 Apr 2020 13:38:10 GMT

well it is not the matter of "have to". It is just that using app_usbd for handled trasactions would make the behavior more predictable and easier for us

RE: USB throughput for nRF52840

henryh — Thu, 16 Apr 2020 13:28:52 GMT

Do I have to use app_usbd for handled transactions to work?

RE: USB throughput for nRF52840

henryh — Thu, 16 Apr 2020 12:35:30 GMT

I'm using the NORDIC USB stack; built my code on the USBD example which uses the USBD driver. There is no example that implements WINUSB (WCID) which was a requirement for the implementation.

RE: USB throughput for nRF52840

Susheel Nuguru — Thu, 16 Apr 2020 11:20:46 GMT

Hi Henry,

Seems like you are using your own USB stack? I think you should try app_usbd and see if it works

RE: USB throughput for nRF52840

henryh — Wed, 15 Apr 2020 21:16:05 GMT

update: I was able to get the USBD code to hook up to WINUSB and it is currently running about 200 KB/s using nrfx_usbd_ep_transfer() with the event handler. I would increase throughput by implementing handled transactions but was unable to get that working. After calling nrfx_usbd_ep_handled_transfer() for EPIN1 I can follow execution into the callback function but the endpoint never seems to send the data. I can't find anything wrong with the functions involved but have included them below. Any ideas?

// *****************************************************************
// function: usbd_start_tx
// purpose: start a handled TX transaction. This code starts up
//            the TX using a handled transaction that automatically
//            will pull data from the TX FIFO until it is emptied
//            using a call back function.
// passed:   nothing
// returns: nothing
// notes:    none
// *****************************************************************
inline void usbd_start_tx(void)
{

if(nrf_drv_usbd_ep_is_busy(NRFX_USBD_EPIN1)==false)
{
    if(fifo_empty(TX_FIFO)==false)
    {
      //data available so start a handled transaction
      tx_flag=true;
      nrfx_err_t err_code=nrfx_usbd_ep_handled_transfer(NRFX_USBD_EPIN1,&usbd_tx_handler);
/*
//non-handled transactions
      uint32_t size=fifo_rd_tx_fifo((uint8_t*)usb_tx_buff,64);
      if (size>0)
      {

        //push next packet into stack
        usb_tx_xfer.size=size;
        tx_flag=true;
        nrfx_usbd_ep_transfer(NRFX_USBD_EPIN1,&usb_tx_xfer);
       }

    }
}

return;

}//end function

// *****************************************************************
// function: usbd_tx_feeder
// purpose: push data into the USB stack for TX based on calls from
//            the stack itself. This should increase TX throughput
//            by avoiding using SW events for TX processing.
// passed:   p_next transfer structure
//            p_context   pointer to context
//            ep_size     endpoint size
// returns: true        more data for xfer
//            false       no more data
// notes:    this function is part of a "handled" TX transfer and
//            is a callback for TX transfers once they have been
//            started
//
//            cannot transfer data from flash - RAM ONLY!
//
//            we return false with ep_size=0 for no data this can occur
//            if the FIFO is loaded with only 64 bytes
//// *****************************************************************
bool usbd_tx_feeder(nrfx_usbd_ep_transfer_t *p_next, void*p_context,size_t ep_size)
{
//get a 64 byte temporary buffer
uint8_t *buff;

//pop data off the TX fifo into the temp buffer
buff=nrfx_usbd_feeder_buffer_get();

//get some data
ep_size=fifo_rd_tx_fifo((uint8_t*)usb_tx_buff,64);

//update parameters
usb_tx_xfer.p_data.tx=(uint8_t*)usb_tx_buff;
usb_tx_xfer.size=ep_size;
p_next=&usb_tx_xfer;
// p_context=NULL;

//is there any more data in TX FIFO?
if(fifo_empty(TX_FIFO))
{
     //flag feeder needs priming
     tx_flag=false;
     return(false);
}
else
{
    return(true);
}
}//end function