The problem is the ST-Link protocol on top of USB. It is the same as the old
ST-Link V2.
Packet 1: Host->Device: host ask how many bytes are available
P2: H<-D: ack
P3: H->D: read request
P4: H<-D: number of bytes available
P5: H->D: read request
P6: H<-D: SWV data (eventually split in several packet of 512 bytes each)
Every packet has to pass through the OS stack and be handled by the
application. This adds plenty of delays between the packets.
The only possible optimization is to send together P1 and P3 in the OS queue
and wait for P2 and P4, but this should be already done with USE_LIBUSB_ASYNCIO.
The rest must be sequential!
And this must be repeated in a loop to sustain the SWV transfer.
The max we can transfer at each iteration is 2 kbyte, but the closer we are to
this limit the easier we loose data that cannot be buffered by the ST-Link. We
have to go faster, thus taking less than 2 K data at each iteration.
So the 480 Mbit/s cannot be fully used. The CPU load on the host determines the
scheduling of OpenOCD, and OpenOCD can be halted to allow executing other
higher priority tasks. The USB bulk transfer used by ST-Link is by design the
lowest priority transfer in USB spec, with no guaranteed delay nor bandwidth,
so depending on what you have on the same USB port it can impact the transfers
to ST-Link.
To conclude, I'm not saying that 24MHz is impossible (I did not tested), but it
depends on the whole setup. Don't use external USB hubs but connect the ST-Link
directly to one of the PC USB port and check, with 'lsusb', that the USB port
is directly attached to the USB controller, not through some internal USB hub.
Run OpenOCD on the native PC, not in a virtual machine. Stop other applications
that can consume CPU bandwidth. And so on...
---
** [tickets:#283] Speed of SWD with SWV with ST-link V3**
**Status:** new
**Milestone:** 0.10.0
**Labels:** SWV stlink
**Created:** Sat Oct 24, 2020 12:20 PM UTC by Pawel
**Last Updated:** Thu Nov 05, 2020 10:24 PM UTC
**Owner:** nobody
Hi all,
ST-link v3 support SWV up to 24MHz but in openocd it is limited to max 2MHz.
( UM2448 Rev 5 page 18). I work with patched openocd and can verify that it is
working fine with higher speeds that 2MHz.
It can looks like this:
[https://github.com/ntfreak/openocd/compare/master...phryniszak:master?diff=split](http://)
And one more thing - does it make sense to check baudrate like pyocd?
```python
def set_swo_clock(self, swo_clock, system_clock):
"""! @brief Prepare TPIU for transmitting SWO at a given baud rate.
Configures the TPIU for SWO UART mode, then sets the SWO clock
frequency based on
the provided system clock.
@param self
@param swo_clock Desired SWO baud rate in Hertz.
@param system_clock The frequency of the SWO clock source in Hertz.
This is almost always
the system clock, also called the HCLK or fast clock.
@return Boolean indicating if SWO UART mode could be configured with
the requested
baud rate set within 3%.
```
I noticed that some baudrate combinations are giving for some reason wrong
output with openocd.
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/openocd/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list._______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
