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

usb transfer on nrf52840

1.specification says that we should trigger EP0STATUS task to initiate the status stage for control transfer(read/write).

actually nrf52840 will auto ack the OUT TOKEN i.e. the status stage of control read transfer,but nak the IN TOKEN for the control write status stage until we trigger EP0STATUS task.

is this a bug?

2.specification says that we should write any value to SIZE.EPOUT[n] to allow nrf52840 acking OUT TOKEN on a bulk/interrupt out endpoint. but actually, nrf52840 will still nak OUT TOKEN even if we write something to SIZE.EPOUT[n]. instead of writing something to SIZE.EPOUT[n], we should start a dma transfer by triggering STARTEPOUT[n] task, then nrf52840 will ack the OUT TOKEN and transfer data from usbd to user memory and signal ENDEPOUT[n] event.

after ENDEPOUT[n] event, specification says that nrf52840 will nak the next OUT TOKEN until we write something to SIZE.EPOUT[n]. but actually, nrf52840 will always ack the next OUT TOKEN regardless whether SIZE.EPOUT[n] is written or not. we can't control nrf52840 to nak the next OUT TOKEN.

it seems that ack/nak is controlled by STARTEPOUT[n] task instead of SIZE.EPOUT[n]. as a result of this, before acking the first OUT TOKEN sent by host, we must start an ugly dummy dma transfer first,this transfer will always finish immediately with EPOUT[n].AMOUNT=0 regardless whether there is an OUT TOKEN or not, after the dma transfer done, nrf52840 will ack the first OUT TOKEN sent by host.

  • Hi,

    Thank you for reporting this.

    1. Yes, this is a bug. The HW team is working on solving this issue.
    2. It seems that you have found a working solution for the moment. An underlying problem here is that SIZE.EPOUT[n] is write-only at the moment, but should have been RW. "It seems that ack/nak is controlled by STARTEPOUT[n] task instead of SIZE.EPOUT[n]." Note that the behaviour of STARTEPOUT[n] is correct.
Related