Burstiness of nRF 52840 Dev Kit USB CDC ADM code on Mac OS

RE: Burstiness of nRF 52840 Dev Kit USB CDC ADM code on Mac OS

Sigurd — Sun, 13 May 2018 17:33:27 GMT

I'm happy to hear that the issue is resolved.

Yes, this change will be added in the next SDK release.

RE: Burstiness of nRF 52840 Dev Kit USB CDC ADM code on Mac OS

ejg2putt — Sun, 13 May 2018 15:53:58 GMT

I've been testing all weekend and have not seen any burst problems, I think we can declare victory at this point.

Will your changes be rolled into the SDK at some point? I'll make sure our code includes the changes.

Thanks for your help.

RE: Burstiness of nRF 52840 Dev Kit USB CDC ADM code on Mac OS

ejg2putt — Thu, 10 May 2018 01:02:47 GMT

Thanks for the quick response Sigurd,

This does appear to eliminate the problem, I’m able to move 128 byte packets (i.e. single app_usbd_cdc_acm_write) at a 1 KHz rate with minimum jitter and *NO* 4 ms bursts.

I thought we had fixed this before with the double write, so I’d like to test for a few days to ensure the problem doesn’t reappear. I also want to test on Windows, which I won’t get to until this weekend, so I’ll update everyone on the state of things this weekend once I’m done testing.

RE: Burstiness of nRF 52840 Dev Kit USB CDC ADM code on Mac OS

Sigurd — Wed, 09 May 2018 15:26:26 GMT

Hi Ed,

Can you see if this change improves anything ?

ret_code_t app_usbd_cdc_acm_write(app_usbd_cdc_acm_t const * p_cdc_acm,
                                  const void *               p_buf,
                                  size_t                     length)
{
    app_usbd_class_inst_t const * p_inst = app_usbd_cdc_acm_class_inst_get(p_cdc_acm);
    app_usbd_cdc_acm_ctx_t * p_cdc_acm_ctx = cdc_acm_ctx_get(p_cdc_acm);

    bool dtr_state = (p_cdc_acm_ctx->line_state & APP_USBD_CDC_ACM_LINE_STATE_DTR) ?
                      true : false;
    if (!dtr_state)
    {
        /*Port is not opened*/
        return NRF_ERROR_INVALID_STATE;
    }
    
    nrf_drv_usbd_ep_t ep = data_ep_in_addr_get(p_inst);
    
    if ((length % NRF_DRV_USBD_EPSIZE) == 0)
    {
        NRF_DRV_USBD_TRANSFER_IN_ZLP(transfer, p_buf, length);
        return app_usbd_ep_transfer(ep, &transfer);
    }
    else
    {
        NRF_DRV_USBD_TRANSFER_IN(transfer, p_buf, length);
        return app_usbd_ep_transfer(ep, &transfer);
    }
}

Edit: The idea here is to use NRF_DRV_USBD_TRANSFER_IN_ZLP() when you don't have a full packet to send. A Zero Length Packet will be generated on the end of the transfer when using NRF_DRV_USBD_TRANSFER_IN_ZLP(), and it should therefore end the transaction.

RE: Burstiness of nRF 52840 Dev Kit USB CDC ADM code on Mac OS

ejg2putt — Tue, 01 May 2018 23:31:53 GMT

Thanks TJ. A zero byte packet did not work, but a combination of a 96 byte packet and a 32 byte packet fixes the problem. 112/16 did not work, gave me the same burst timing. Don't know what's magic about 32 bytes.

Thanks for all the help.

RE: Burstiness of nRF 52840 Dev Kit USB CDC ADM code on Mac OS

Turbo J — Tue, 01 May 2018 10:23:52 GMT

Either dont't send an integer multiple of 64 byte or send a "zero" packet after sending such a packet.And yes, USB bulk should allow sending a packet that contains no data bytes.

Reason behind this is bulk endpoint handling in the USB spec, that assumes "full" endpoint packets belong to the same transaction. This delays delivery to your application until the transaction is finished.

RE: Burstiness of nRF 52840 Dev Kit USB CDC ADM code on Mac OS

ejg2putt — Tue, 01 May 2018 09:53:28 GMT

Any ideas here? Is there a different USB example/code base we could use to smooth out the transactions. ESB does us no good if we can't get the data across USB in a timely manner.

RE: Burstiness of nRF 52840 Dev Kit USB CDC ADM code on Mac OS

ejg2putt — Tue, 24 Apr 2018 23:41:07 GMT

A bit more info. Tried a few different configurations of packet size, and it appears the minimum "burst" is about 4 ms. Nothing I've been able to do reduces this number, smaller packets just result within the burst window.

Ignoring ESB, I modified the main loop of my code to do nothing but 128 byte app_usbd_cdc_acm_writes (not waiting for any ESB provided data. At 128 bytes, I see a burst of 4 transfers - first one about 1 ms, then the next 3 happening almost immediately. Seems to related to USB transfers????

RE: Burstiness of nRF 52840 Dev Kit USB CDC ADM code on Mac OS

ejg2putt — Tue, 24 Apr 2018 00:03:14 GMT

A bit more data, but I'm not sure it makes any sense:

If I split up the app_usbd_cdc_acm_write into 64 byte packets, I now get a burst of 8 USB reads that are about 7.5 ms apart (i.e. eight 64 byte packets in 7.5 ms, first one takes about 7 ms, the remaining 7 happen almost immediately). I did this both by just splitting up the 128 packet coming across the air into two packets, and by simply xfering a 64 byte across the air (and not manipulating the local buffers at all).. Both produced the same 7.5 burst cluster.

Thinking this might be some sort of USB/CDC/ADM cache flush problem on a 512 byte boundary(4 x 128 = 8 x 64 = 512), I tried the opposite, by faking 256 byte writes by writing the 128 byte packet twice to app_usbd_cdc_acm_write. I was expecting the burst to be around 2 ms, but this produces the same 4 ms burst as with a single 128 byte packet (???).

Need to ponder this some more, I'll post any other data I come up with. But this seems to indicate the problem is somehow getting data thru the USB/CDC/ADM to our app, and not related to the ESB transfer of data.

RE: Burstiness of nRF 52840 Dev Kit USB CDC ADM code on Mac OS

ejg2putt — Mon, 23 Apr 2018 10:43:43 GMT

Already measured the interval. In nrf_esb_event_handler, I recorded the time stamp of the received packet for the NRF_ESB_EVENT_RX_RECEIVED case of p_event->evt_id. The time stamp is based on the 32 KHz clock. I recorded the time stamp in the received data so I could look at it after the transfer was complete.

The time stamp always show exactly 32 counts between packets, +/- 1 count. So I would say that the data across the air is coming in at exactly 1 KHz rate (i.e 1 ms between packets).

I will try different packet sizes later today.

RE: Burstiness of nRF 52840 Dev Kit USB CDC ADM code on Mac OS

Sigurd — Mon, 23 Apr 2018 08:28:52 GMT

Hi,

Could you measure the interval between the APP_USBD_CDC_ACM_USER_EVT_TX_DONE events?

Do you see the same beahvior if you split your 128 byte packets in two, i.e. use 64 bytes per packet for app_usbd_cdc_acm_write instead?