tree 1f633669512b096d21899996881d1625405439de
parent 7530f13031c8e316131fe6272f7905db1245cfd9
author hathach <thach@tinyusb.org> 1786681777 +0700
committer hathach <thach@tinyusb.org> 1786943820 +0700
gpgsig -----BEGIN SSH SIGNATURE-----
 U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgb6YGDwEfkq0Z/piKbImQli0dNd
 ofcOD25nqRbKt/L2IAAAADZ2l0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5
 AAAAQOHR7tvmjCB+zMRtxJ5VKucwF0j6Ol3sEj5r7VXf0lVrC9T4snCgRT0RLrySyz0YXs
 F+dB0cU0D6m7q1MXszLg8=
 -----END SSH SIGNATURE-----

portable/nrf5x: complete zero-length bulk OUT transfers

A zero-length OUT read (e.g. the MTP driver's read for the host's
terminating data ZLP) could never complete when the ZLP's EPDATA
arrived after the read was armed: actual_len < total_len is always
false for total_len == 0, so the handler only set data_received and the
armed transfer hung forever, wedging both bulk endpoints (host sees
pure NAK; EP0 stays alive). Run the 0-byte DMA in that case to drain
the endpoint and complete the transfer, matching what the arm path
already does when the ZLP arrives first.

Found via usbmon on the HIL rig: device/mtp on feather_nrf52840_express
wedged after SendObject's terminating ZLP whenever the class armed the
read before the host's (NAK-delayed) ZLP retry landed - deterministic
under CI load, which is why PR CI only passed this test on a re-flash
retry (21.4 s vs the normal 2.2 s).