ST-LINK/V3 ?

[SiliconWizard]

OpenOCD does now support the v3, however it has to be a reasonably recent build. I think something from 2019 (im not sure the exact date).

I just pulled the latest from git and built it. Then took a look. Yes, the V3 is now supported indeed. Note that now you have to use the common 'stlink.cfg' script which handles all ST-LINK versions up to V3 (before that there were separate scripts for each version up to ST-LINK/V2-1).

[EmBlocks]

However i think im am going to look into EBLink. the ability to auto detect and run the correct script for ST processors sounds very appealing.

Sure, give it a try

[bson]

If you want to use OpenOCD, AFAIR, it has support for the V2 but not (yet?) for the V3.

I use it with V3 and have for the better part of a year.  Works just fine.

Not sure which release that would be since I usually pull and build it myself.

[lawrence11]

https://www.digikey.ca/product-detail/en/stmicroelectronics/STLINK-V3MINI/497-19530-ND/10266291?utm_adgroup=General&utm_source=google&utm_medium=cpc&utm_campaign=Dynamic%20Search_FR_RLSA_Buyers&utm_term=&mkwid=sgb4JkSDi&pcrid=399612180233&pkw=&pmt=b&pdv=c&productid=&slid=&gclid=Cj0KCQiA0NfvBRCVARIsAO4930ntHQrEM4QwFujSZDY4qQK-nla156HBM5aLf2C_xuygqF4a02wbTy4aAibYEALw_wcB

So I just managed to communicate with my 2x cortex M chips on my custom board.

With ST-Link V3. I have a mini cortex header 10pin SWD 1.27mm

But I wish to try the mini, with a shorter ribbon, since I omitted series resistor on SWO line.

Where could short ribbon cables be found for Mini Cortex header?

[lawrence11]

https://odseven.com/products/raspberry-pi-10-pin-2x5-socket-socket-1-27mm-idc-ribbon-flat-cable-with-75-150mm-long

sounds good?

Am I overreacting?

[pigrew]

But I wish to try the mini, with a shorter ribbon, since I omitted series resistor on SWO line.

Where could short ribbon cables be found for Mini Cortex header?

I've never had any length-related issues in the past, but by your questions I assume you are running into issues?

The mini comes with a ~4 in cable in the box, so I'd start with it. Also note that the st link header is 14 pin, so you need a 14-pin cable (unless you replace the st link connector). The center 10 pins are compatible with the standard header.

The st link mini has a bunch of 47ohm resistors on the back, I assume in series with the lines, so perhaps you already have a series termination. (I've not fully traced the circuit, so I can't definitively state that they are in series)

Another option would be to directly solder a female 14 pin header onto your PCB, removing the need of a cable at all.

[frogblender]

A friend is using the STLINK-V3MINI with the STMCUBE development environment which is Eclipse based and said it is significantly faster to startup, program and debug compared to the V2. He said once he builds, he can have the chip programmed and running in a second. The chip he is using in a STM32F4. I do not know the size of his code but would imagine it to be in the 20k to 40k range.

Can you ask your friend wtf is up?   I see big fat diddly difference between V2 and V3.   About 12 seconds (excluding build time, of course)  with either V2 or V3.   The actual flashing of the flash is about a second or two, but the rest of the crap is the problem (starting the GDB server - maybe 3 or 4secs.   Invoking the "STM32CubeProgrammer"... this seems to take 4 seconds just to start up).

I tried on both TrueStudio, and the new CubeIDE.  V2 and V3.   12 seconds ±1 on everything.


12 seconds is tooo long - in that time I forget what code changes I just made.

[frogblender]

Reflash speed:  I'm now a 5 seconds flat (not including build time) to upload/reflash and start gdb debugging. 

V3Mini: 5 seconds
V2:       6 seconds

To go faster, I needed to:

A)  GDB server is always running (start it manually from the batch file in C:\Program Files (x86)\Atollic\TrueSTUDIO for STM32 9.3.0\Servers\ST-LINK_gdbserver) (this step saves 3 or 4 seconds).

B) gdb will call, when needed, STM32_Programmer_CLI.exe  which actually does the reflashing.  It needs to be called with --skiperase , which means it will not erase flash blocks before rewriting them (saves 4 seconds).  This may cause problems for virgin flash, or when your code grows into the next block.

[EmBlocks]

We are using a TAG-connect on our boards. This only need a PCB shape without any assembly. TAG-connect it self is rather expansive but the possibility to hook any board to the debugger without any cost is very nice.

I don't know what flash strategy TrueStudio GDB is using but writing the flash directly, the Jlink way, is significantly faster as the RAM loader method. I started with EBlink with the ram loader scripts (still in git at the old commits) but now I'm busy rewriting the flash scripts to direct write. If an interface is too fast for a particular chip, decreasing the SWD speed temporarily, wins over ram loaded busy polling method.

[OwO]

The st-link does flashing in an inefficient way and it's not hard to beat it. I have a custom bootloader for the F303 that takes 4 seconds to flash the same binary that takes st-link 12 seconds.

The way st-link flashing works is first a mini-program is loaded into RAM and ran on the MCU, and this program performs the flashing while st-link transfers data one page at a time. The inefficiency comes from the order that things are done, which is first ALL pages are erased and then all pages are programmed, as well as the fact that the mini-program ("flash loader") is written in assembly and extremely primitive so can not accept data while flashing is happening (there is just a single buffer that is written to and read from). The slowest part of flashing is erasing, so it's important that you can erase and accept new data at the same time. My bootloader uses a FIFO, and performs erase-program of pages on the main thread* while accepting of new data happens in an interrupt handler, so the two can happen almost simultaneously. * There is no threading used. Interrupts can preempt program execution so it is considered a different "thread".

However none of this has anything to do with the st-link v3. You can get the same speedup with st-link v2 by simply writing a better flash loader.

[EmBlocks]

Yes, I think that this has something to do with STlinkV3 (or better, the speed of the interface)

If the interface is fast enough you could skip all the "complex" stuff with fifo'ing will erasing etc because it wont bring you any speed gain over waiting for erase complete and write directly. The fact is, you can only reflash after erase is done and flashing takes an amount of time. Ideal would be if the transfer time of the interface is equal to the flash time of that data burst. I think that this would give you the maximum flash speed achievable and faster than any RAM flash loader strategy.

P.S. I think that your way of pre-writing a buffer during erase could be very nice for the rather slow speed connections (harsh environment etc). I will try it in a dedicated flash script and test what the time gain will be, thanks for the tip!

[Jeroen3]

The ST Link performs a full erase and then multiple write-verify cycles. That's why it's slow. If you use a segger or ulink without verify it's also very fast.
It does this since you could ask for OTP flags, and then verify won't work after completion.

[EmBlocks]

I don't think so,  the STlink is only a low-level interface. The intelligence is coming from the software driving the STlink. And yes, I agree that Segger discovered that direct writing was faster at some point. The early versions also didn't use direct writing.

Reading doesn't take long, EBlink is first reading the current content  at startup to fill the cache so it can skip unmodified sectors, this only takes less than a second for 250Kbyte image (H7) with a stlinkV3. So verify isn't that expansive. A flash write takes a certain amount of time which is specified by the vendor. If your transfer speed, the speed to fill the shift register on target side, is lower or almost equal to the worst case flash time, then there is no need to check the busy status of the flash and there is no need to use an external flash loader on target. 

[jusaca]

Is it only me or is it not possible to close the case of the ST-Link-v3set when the adapter board is used?
Overall I'm more than underwhelmed by the usability of the V3... Even without the adapter board, the case seems like a fail to me! The pins for the programming cable are at the bottom? Either the st-link is not lying on a flat surface, because the cable is coming out of the bottom, or the LEDs are faced down?!

But because I want to use the big 20 Pin header I can't even close the case 

[szszoke]

Is it only me or is it not possible to close the case of the ST-Link-v3set when the adapter board is used?
Overall I'm more than underwhelmed by the usability of the V3... Even without the adapter board, the case seems like a fail to me! The pins for the programming cable are at the bottom? Either the st-link is not lying on a flat surface, because the cable is coming out of the bottom, or the LEDs are faced down?!

But because I want to use the big 20 Pin header I can't even close the case 

It's not just you. If you use the adapter, you cannot close the case.

[jusaca]

It's not just you. If you use the adapter, you cannot close the case.

Well, that's just... great 
Na, my fault to not read carefully before buying one instead of a proven v2 one

[harerod]

Question: Is there a a ST-UTIL-like CLI tool available for the V3 that can be run from a Windows-Batchfile?


Example, what I would do with a ST-Link V2:
ST-LINK_CLI.exe -c JTAG UR -ME -P firmware.hex -V -HardRst

My own search didn't yield anything useful.

Backstory: One of my clients got a V3 with a custom adaptor from a former contractor. Since they are abroad I have no physical access to that contraption. There are no IT/electronics experts available at their place, hence my wish to make them double-click and run a batchfile.

[gamalot]

Question: Is there a a ST-UTIL-like CLI tool available for the V3 that can be run from a Windows-Batchfile?


Example, what I would do with a ST-Link V2:
ST-LINK_CLI.exe -c JTAG UR -ME -P firmware.hex -V -HardRst

My own search didn't yield anything useful.

Backstory: One of my clients got a V3 with a custom adaptor from a former contractor. Since they are abroad I have no physical access to that contraption. There are no IT/electronics experts available at their place, hence my wish to make them double-click and run a batchfile.

There is STM32_Programmer_CLI.exe

On my PC, it is located in the C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin

[harerod]

Thank you, I don't have that on my system. Could you tell me which software packets / version you had to install for this? Much obliged.

[gamalot]

Thank you, I don't have that on my system. Could you tell me which software packets / version you had to install for this? Much obliged.

It's the STM32CubeProgrammer

https://www.st.com/en/development-tools/stm32cubeprog.html

[harerod]

Thank you for helping me out. I saw that page earlier, but it didn't mention CLI (the docu contains some info, though).

edit: successfully tested STLINK-V3 under Win10 with STM32F407VG

[harerod]

You just gotta love ST. Their favorite hobby is rewriting interfaces for tools and libraries. Here are some differences between the V2 ST-LINK_CLI.exe and the new STM32_Programmer_CLI.exe. Tests were done on Win10. Behold the subtle changes in the commands since ST-Link CLI v3.6.0.0.

There is not much chance for a small, compact programming package. Just install en.stm32cubeprg-win32_v2-7-0.zip, which includes all drivers and libraries. The STM32_Programmer_CLI.exe won't even run without the QT5-DLLs and heaps of other stuff.

How to build simple BATchfiles for programming an STM32F4 (connect under reset, 4MHz clock):

rem name the burntool
set burntool="C:\Program Files (x86)\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe"

rem complete memory dump 1MB
rem V2: stlutil\ST-LINK_CLI.exe -c JTAG UR -Dump 0x08000000 0x100000 dump.hex
%burntool% -c port=SWD freq=4000 INDEX=0 mode=UR -r 0x08000000 0x100000 firmware\firmware_dump.hex

rem do a mass erase and burn the firmware.hex, end with hard reset
rem V2: stlutil\ST-LINK_CLI.exe -c JTAG UR -ME -P firmware\firmware.hex -V -HardRst
%burntool% -c port=SWD freq=4000 INDEX=0 mode=UR -e all -w firmware\firmware.hex -v -hardRst

rem do a selective erase of sectors 0..7 and burn the firmware.hex, end with hard reset
rem V2: stlutil\ST-LINK_CLI.exe -c JTAG UR -SE 0 7 -P firmware\CubeMain.hex -V -HardRst
%burntool% -c port=SWD freq=4000 INDEX=0 mode=UR -e 0 7 -w firmware\CubeMain.hex -v -hardRst

[Flomen]

I draw a custom ST Link V3 using KiCad, this is my project files.