Rationale:
In USB device mode, the f103 chip provides 512 bytes
of memory for USB traffic. In the 'master' branch
of the blackmagic probe, the control endpoint pipe size
is set to 64 bytes, effectively consuming a quarter
(1 'in' endpoint, 1 'out' endpoint == 2 endpoints,
2 /* endpoints */ x 64 /* bytes per endpoint */ == 128 bytes
out of 512 /* bytes of precious usb packet memory */).
The USB standard, for full speed devices, does allow
a control endpoint size of 8 bytes.
I am not too aware of all the details of the USB standard,
but the USB standard seems to allow fragmented transactions
on the control USB pipe (endpoint 0), which libopencm3
apparently supports:
libopencm3/lib/usb/usb_control.c:usb_control_send_chunk()
I am using this change (from 64, to 8 bytes)
on a windows 10 machine, on an stlink hardware
('PROBE_HOST=stlink'). It works on my machine.
This change can potentially provide other USB endpoints
in the blackmagic firmware with more memory
3e3e450 reduced the buffer size for the UART interface OUT endpoint to
32B, but left wMaxPacketSize at 64B. This effectively configures the
hardware to receive packets up to 32B in size while telling the host it
can send larger packets. On reception of a larger packet, the usb core
treats it as an error, drops the packet and replies with a STALL
handshake.
This commit fixes the issue by updating the descriptor to match the
buffer configuration.
Fixes#538
With 128 bytes for both usb_uart buffers, traceswo gives errors!
Keep the size for the receive buffer and diminisch the transmit buffer,
as there is no flow control to the device.
Probably related to https://github.com/libopencm3/libopencm3/issues/477
