You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Something goes wrong when the size of an IN control transfer is an exact multiple of the packet size (64 bytes). This is perhaps easiest to test by trying out a string descriptor that is 31 characters long. I haven't investigated exactly what happens, but I suspect that two zero-length packets are sent when only one is mandated.
Unless I'm missing something, there's also another issue: according to USB 1.1 section 5.5.3, a zero-length packet should not be sent after the last packet, if data_p->len == len_asked, even if the the last packet is full.
Presumably these situations have never come up so far, so they are hardly critical, but they are certainly nasty pitfalls in waiting.
The text was updated successfully, but these errors were encountered:
Something goes wrong when the size of an IN control transfer is an exact multiple of the packet size (64 bytes). This is perhaps easiest to test by trying out a string descriptor that is 31 characters long. I haven't investigated exactly what happens, but I suspect that two zero-length packets are sent when only one is mandated.
The easiest way to fix this is to change
<
to<=
in https://github.com/im-tomu/tomu-bootloader/blob/master/toboot/usb_dev.c#L242 but I believe it's also possible to get rid ofrequire_zlp
altogether so then the current comparison is correct: the packet is last if it is not full.Unless I'm missing something, there's also another issue: according to USB 1.1 section 5.5.3, a zero-length packet should not be sent after the last packet, if
data_p->len == len_asked
, even if the the last packet is full.Presumably these situations have never come up so far, so they are hardly critical, but they are certainly nasty pitfalls in waiting.
The text was updated successfully, but these errors were encountered: