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 of require_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.
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_zlpaltogether 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.