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
And one more thing - does it make sense to check baudrate like pyocd?
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.
Interesting... I'm checking it!
The link seams broken. Can you send it again?
https://github.com/ntfreak/openocd/compare/master...phryniszak:master?diff=split
Looks like sourceforge is blocking link tag.
I received confirmation that the max SWV freq on ST-Link v3 is 24 MHz. Good.
But then, depending on the amount of data generated on SWO, the bottleneck can become the USB connections. So be sure to not exaggerate otherwise data could be lost.
Are you willing to send your patch on OpenOCD gerrit http://openocd.zylin.com ?
Regarding the other question about checking the baudrate.
We already have merged two patches for J-Link
http://openocd.zylin.com/5807
http://openocd.zylin.com/5846
and there is ongoing a patch for cmsis-dap.
I was planning to use the same method for stlink, after the patches for TPIU get merged
http://openocd.zylin.com/#/q/topic:tpiu
Antonio
The ST-Link v3 is USB-HS (480MBit/s), so bandwidth should be no concern.
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...
Hi Antonio,
I think I leave it to you. It would take me a while to get my head around openocd source control.
Regards,
As you want, but please check the 'HACKING' file, it's not so complicated for you that already master git.
I will mainly cherry-pick from your github with minor changes. What should I put as author?
Pawel phryniszak@users.sourceforge.net ?
It can be your name. It is really small thing.
On Fri 30 Oct 2020, 20:46 Antonio Borneo, borneoa@users.sourceforge.net
wrote:
Related
Tickets: #283
It can be your name. It is really small thing.
http://openocd.zylin.com/5908
Other topic mentionned in this ticket in http://openocd.zylin.com/5909