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
* Rename variant_string
Files efm32 samd samx5x uses same function name that collides during
linking (checked with gcc10)
Signed-off-by: Alexey 'Alexxy' Shvetsov <alexxyum@gmail.com>
* Also make xxx_variant_string static
Signed-off-by: Alexey 'Alexxy' Shvetsov <alexxyum@gmail.com>
Option bytes are not accessible with level 1 protection, so
Use FLASH_OPTCR(x)
Fix crash with "mon opt write xxxx"
Handle option manipulation better when HW Watchdog fuse is set
Allow abbreviated "mon option x<yyy>" commands
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
The swolisten program failed to print the cbw buffer correctly while
in dump mode. As printf() is used to print the dump, it is expected
that the cbw buffer is zero-terminated, which would only be
the case, if the cbw buffer is initialized with zeros, before filling it
with new data. One could set the entire cbw buffer to zero, but it
will be more efficient to only set the size-th byte to zero.
Furthermore, if a '%' character appears in the data, printf() will
attempt to format it, causing unexpected results.
This patch fixes the above 2 problems, by:
1. using the size variable to set the size-th byte of the cbw
buffer to zero, before passing it to printf().
2. calling printf() with a "%s" formatting string, followed by the
data buffer, cbw.
