ST-LINK/V3 ?

[photovore]

When updating my IAR compiler service pack I saw that ST-LINK V3 support was one of the new features. Is there any info concerning this new version of the debugger? I quite enjoy the integrated UART in the ST Dev Boards and was wondering when they would add the feature to their official hardware.  Higher SWD speeds also wouldn't hurt.

[ajb]

Looks like it's already for sale: https://www.aliexpress.com/item/New-STLINK3-st-link3-st-link-V3-STM32-STM8-emulator/32815460150.html

[andersm]

The STM32CubeProgrammer manual gives 24000kHz SWD and 21333kHz JTAG frequencies for the ST-Link v3 (via).

[technix]

The STM32CubeProgrammer manual gives 24000kHz SWD and 21333kHz JTAG frequencies for the ST-Link v3 (via).

That usually means 96MHz or higher core clock. What for?

[lucazader]

It appears this is now in stock at both digikey and mouser:
https://www.digikey.com/product-detail/en/stmicroelectronics/STLINK-V3SET/497-18216-ND/9636028
https://nz.mouser.com/ProductDetail/511-STLINK-V3SET

Here is a recently added technical doc that was added to ST's website explaining the differences in the different ST-link versions, it includes info about the ST-Link V3:
https://bit.ly/2QuEBOd

Headline features:
Based on STM32F723IE processor
USB 2.0 HS interface (rather than FS on all older stlinks)
Integrated VCP port with frequency up to 15MHz (assuming this means up to 15mhz uart)
USB Bridge interface with support for: SPI/UART/I2C/Can?GPIO

In addition to this the STCubeProgrammer has been updated to V1.2 which apparently now fully supports the V3 hardware.
Assuming the 24MHz SWD frequency still stands, but cant find any more info on this.

[richardman]

That "USB 2.0 HS interface (rather than FS on all older stlinks)" could be very useful.

Currently STLINK is very slow, especially with the ST-LINK GDBserver, but apparently that's just because they have not upgraded the programming algorithm yet, but a faster interface should help.

[ajb]

USB HS is hardly likely to make any difference at all in many cases.  Programming time is dominated by the erase/write timing of the flash; the time it takes to move the data from the PC to the debug probe is nothing by comparison.  Anyway, ST parts max out at, what, 2MB of flash?  It's possible that the new probe will be accompanied by better algorithms and better software support, though, which would be quite welcome.  I especially hope it now properly supports connecting to a running target, and doesn't need to be power cycled if it falls to connect to the target, like the V2.  Personally I'll probably stick with the J-link, which is waaaaay faster and more reliable than the V2.

[ajb]

More info available now, including what the hardware looks like.  The adapter board is as big as the probe is!  Looks like it can be stacked into the same housing as the probe which is sort of neat, but I would rather have a slightly larger device than one that has pins and cables coming off of every side.

https://www.st.com/content/st_com/en/products/development-tools/hardware-development-tools/development-tool-hardware-for-mcus/debug-hardware-for-mcus/debug-hardware-for-stm32-mcus/stlink-v3set.html#design-scroll

[SiliconWizard]

It's only 3 V to 3.6 V apparently which sucks. There seems to be an adapter board for 1.65 V to 5.5 V but I'm not sure what SWIM is exactly.

[andersm]

I'm not sure what SWIM is exactly.

It's the debug protocol for ST8 micros.

[SiliconWizard]

Thanks, so I take it that for STM32's you are stuck with 3V min (unless you add your own level shifters)?

[trevwhite]

I was going to buy one of these but seems they are now unavailable? Production issue? Design issue? Anyone have any idea what happened to supply?

Trev

[SiliconWizard]

Indeed: https://www.st.com/en/development-tools/stlink-v3set.html

Guess you'll have to contact them as they suggest.

[Mr. Scram]

It's only 3 V to 3.6 V apparently which sucks. There seems to be an adapter board for 1.65 V to 5.5 V but I'm not sure what SWIM is exactly.

What would be the practical implications of the voltage limitation? I was thinking of buying a V3, but maybe a V2 is more versatile.

[SiliconWizard]

It's only 3 V to 3.6 V apparently which sucks. There seems to be an adapter board for 1.65 V to 5.5 V but I'm not sure what SWIM is exactly.

What would be the practical implications of the voltage limitation? I was thinking of buying a V3, but maybe a V2 is more versatile.

Well, I guess you wouldn't be able to use it on a board powering the MCU at any voltage under 3V. You may not design any and in this case, no bother. I happen to use Vdd's anywhere from 1.8V to 2.7V in some of my designs, so that would be a problem.

The V2 was a lot more flexible: "1.65 V to 3.6 V application voltage supported on the JTAG/SWD interface and 5 V tolerant inputs".

[lucazader]

You would have to assume that this new board would be compatible with lower voltage targets on the SWD pins, given they just announced the STM32L5 series that is specifically targeted at this sort of low power low voltage type of application.
I have ordered one from digikey, but not sure when it will arrive...
I can try and test it out at a lower voltage when mine gets to me? However all my designs are 3v3, so might have to modify a nucleo board or something to test this..?

[technix]

I think ST may have a Vpp problem when writing Flash below 3.3V, so it just doesn’t make sense to support anything lower just not to trigger those bugs.

[Mr. Scram]

I think ST may have a Vpp problem when writing Flash below 3.3V, so it just doesn’t make sense to support anything lower just not to trigger those bugs.

That sounds like a great way of getting people to look at other manufacturers.

[SiliconWizard]

I think ST may have a Vpp problem when writing Flash below 3.3V, so it just doesn’t make sense to support anything lower just not to trigger those bugs.

I've only used the L4 series so far, but never ran into such issues with them. Could you point us to some official erratum that clearly states this and what series/models are affected?

If this happens to be true for some models or worse, maybe for ALL of them as you seem to suggest, that would not bode well for ST at all. How would you be supposed to power your MCU at voltages below 3.3V and still be able to program them in-circuit (or have them self-program)? (Except having to design pretty convoluted circuits that can switch to 3.3V just for programming?!)

[technix]

I've only used the L4 series so far, but never ran into such issues with them. Could you point us to some official erratum that clearly states this and what series/models are affected?

If this happens to be true for some models or worse, maybe for ALL of them as you seem to suggest, that would not bode well for ST at all. How would you be supposed to power your MCU at voltages below 3.3V and still be able to program them in-circuit (or have them self-program)? (Except having to design pretty convoluted circuits that can switch to 3.3V just for programming?!)

You just need a diode between the STM32 Vcc and main power rail. This way when programming the programmer/debugger can inject a 3.3V into the STM32 power domain without affecting the rest of the system. As of self program, you are not supposed to do that without a high enough Vcc in the first place. My usual F0 and F4 series can have flaky programming behavior at 2.5V or lower.

That sounds like a great way of getting people to look at other manufacturers.

You are not supposed to program at lower voltages in the first places as documented, and for most uses I know of the STM32 does operate with a 3.3V rail. I feel that ST is just not bothering with the maybe 5% case anymore.

[SiliconWizard]

You just need a diode between the STM32 Vcc and main power rail. This way when programming the programmer/debugger can inject a 3.3V into the STM32 power domain without affecting the rest of the system.

I don't like that. I don't like a voltage drop between the MCU's VDD and the rest of the system in normal condition.

You are not supposed to program at lower voltages in the first places as documented, and for most uses I know of the STM32 does operate with a 3.3V rail. I feel that ST is just not bothering with the maybe 5% case anymore.

I think you're stuck to the F-series/"high-performance" STM32's. Operating voltages below 3.3V are very common in low-power, battery-operated designs. And the STM32L series are targetted at this market, and very well positioned actually. I have read nothing about a higher min programming voltage than the min operating voltage (1.71V as I reckon) in the L4 series datasheets.

I'm looking for this info in a STM32F407 datasheet right now and now get why you said that. Seems specific to the F4 (and maybe other F-series). There's a stated Vprog which depends on the program width actually. 32-bit programming requires 2.7V min, but 8-bit programming can be done at 1.8V, so there's still a way to program them reliably down to 1.8V provided that you can force the 8-bit programming mode. There's no such restriction that I know of for the L-series, they don't even mention specific Vprog figures.

I'm guessing this limitation on the STLINK/V3 vs. V2 comes more from a cost reduction strategy than anything else. Since it's a stated "modular" design, they may release a wider operating voltage through some adapter for JTAG/SWD later on.

As for me, I'll definitely stick to a JTAG-lock-pick Tiny 2 which is much faster than the STLINK (at least up to V2), works down to 1.4V and can be used with many other chips.

[Jeroen3]

It looks like it will support the 1.27mm connector. No need to use adapters boards!

[technix]

You just need a diode between the STM32 Vcc and main power rail. This way when programming the programmer/debugger can inject a 3.3V into the STM32 power domain without affecting the rest of the system.

I don't like that. I don't like a voltage drop between the MCU's VDD and the rest of the system in normal condition.

There are some low leakage perfect diode circuitry available.

You are not supposed to program at lower voltages in the first places as documented, and for most uses I know of the STM32 does operate with a 3.3V rail. I feel that ST is just not bothering with the maybe 5% case anymore.

I think you're stuck to the F-series/"high-performance" STM32's. Operating voltages below 3.3V are very common in low-power, battery-operated designs. And the STM32L series are targetted at this market, and very well positioned actually. I have read nothing about a higher min programming voltage than the min operating voltage (1.71V as I reckon) in the L4 series datasheets.

I'm looking for this info in a STM32F407 datasheet right now and now get why you said that. Seems specific to the F4 (and maybe other F-series). There's a stated Vprog which depends on the program width actually. 32-bit programming requires 2.7V min, but 8-bit programming can be done at 1.8V, so there's still a way to program them reliably down to 1.8V provided that you can force the 8-bit programming mode. There's no such restriction that I know of for the L-series, they don't even mention specific Vprog figures.

I'm guessing this limitation on the STLINK/V3 vs. V2 comes more from a cost reduction strategy than anything else. Since it's a stated "modular" design, they may release a wider operating voltage through some adapter for JTAG/SWD later on.

As for me, I'll definitely stick to a JTAG-lock-pick Tiny 2 which is much faster than the STLINK (at least up to V2), works down to 1.4V and can be used with many other chips.

I do use mostly the F-series. If the Vpp problem originated from me getting questionable Chinese chips things are explained.

Now it feels odd to me that they did not implement proper bidirectional level shifting. AFAIK the whole level shifting thing can be easily handled using a few 74LVC1T45/2T245’s, and their previous hardware do have those.

[SiliconWizard]

Now it feels odd to me that they did not implement proper bidirectional level shifting. AFAIK the whole level shifting thing can be easily handled using a few 74LVC1T45/2T245’s, and their previous hardware do have those.

As said above, I'm pretty sure this is for cost reduction reasons. The V3 design looks like a low-cost version of the V2 in almost all aspects. The HS USB probably costs only a few cents more if even so and doesn't make up for the fact everything else is worse: the V2 had an isolated version, I haven't seen that for the V3. The V2 case was a lot better. And so on...

And I really suggest using other tools than the STLINK if you can. But this V3 looks like a great disappointment so far.

[technix]

Now it feels odd to me that they did not implement proper bidirectional level shifting. AFAIK the whole level shifting thing can be easily handled using a few 74LVC1T45/2T245’s, and their previous hardware do have those.

As said above, I'm pretty sure this is for cost reduction reasons. The V3 design looks like a low-cost version of the V2 in almost all aspects. The HS USB probably costs only a few cents more if even so and doesn't make up for the fact everything else is worse: the V2 had an isolated version, I haven't seen that for the V3. The V2 case was a lot better. And so on...

And I really suggest using other tools than the STLINK if you can. But this V3 looks like a great disappointment so far.

v3 bumped the processor to a F7 from a F103, a fairly significant jump, so unlikely to be a cost reduction revision.

[josip]

The STM32CubeProgrammer manual gives 24000kHz SWD and 21333kHz JTAG frequencies for the ST-Link v3 (via).

Don't see how this can improve anything. Pushing communication rate to insane level.
What cable should be used for connecting target device? HDMI Maybe?

That "USB 2.0 HS interface (rather than FS on all older stlinks)" could be very useful.

FS CDC can go up to 1 MByte/second. I don't see this rate as bottle neck for any flashing tool.

As always, it is all about bloated software.

[andersm]

It could be useful for tracing. ST have a Windows utility that visualizes the values of variables in real-time. Higher bandwidth could allow for monitoring more variables at a higher rate.

[SiliconWizard]

v3 bumped the processor to a F7 from a F103, a fairly significant jump, so unlikely to be a cost reduction revision.

Big deal. Yes it's a big jump in terms of performance, but on a cost level, the F7 they used is approx $8 by 1000 and the F103 approx $3.5 (public price, to get an idea). And they probably want to phase the F1 series out of new designs at ST anyway. Besides, I'm pretty sure ST has preferential rates on ST parts.

There is practically nothing else on the PCB apart from a few passives and probably a couple regulators and protections diodes.
Looking at the design only, it could very well cost less that a V2. Or at worst be in the same ballpark.

As for performance, it's obviously going to be much faster, but is that going to really impact use in the field? Maybe for tracing as andersm said. To be fair, V2 or V3, those are low-cost dev. tools at $35. So the pricing is certainly right. Nothing to complain about here.

But still not impressed one bit.

[gamalot]

I have designed a bottom cover for my ST-Link V3. 

https://www.thingiverse.com/thing:3163349/files

[Mr. Scram]

At least the cobbling together of your programmer is consistent with the rest of the STM toolchain.

[bson]

Is the V3 protocol compatible with the V2?

[frogblender]

Is the V3 any faster?

Starting a gdb debug session in TrueStudio:  time from pressing "Debug" (F11 in my case) to code executing on the target:

V2 = about 10 seconds.
V3 = ?


On the v2, of the 10 seconds... less than 2 seconds are spent flashing the flash.   The rest of the time is "Waiting for debugger connection..." and stuff like that.

[Sal Ammoniac]

The V3 does download code to a board faster, but the "Eclipse overhead" is still there to make starting a debug session seem slow on tools like TrueStudio and STM32CubeIDE.

[AE7OO]

Greetings,

As far as cost goes, as of about 5 mins ago, you could get a STLINK-V3MINI from Digi-Key for $10.37.
STLINKV3MINI

And Mouser has them for $9.75..  STLINK-V3MINI

It looks like it does almost everything the big one does. Except take the adapter boards..

[Harjit]

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.

[langwadt]

Greetings,

As far as cost goes, as of about 5 mins ago, you could get a STLINK-V3MINI from Digi-Key for $10.37.
STLINKV3MINI

And Mouser has them for $9.75..  STLINK-V3MINI

It looks like it does almost everything the big one does. Except take the adapter boards..

so it is basically cheaper than buying the MCU, could also be useful ad a small dev board if you don't need too many pins

[thm_w]

so it is basically cheaper than buying the MCU, could also be useful ad a small dev board if you don't need too many pins

It is a good value.
STM32F723 if anyone is wondering: https://www.st.com/en/microcontrollers-microprocessors/stm32f723ze.html
216MHz, 512kB flash, 256kB ram.

Yeah not so many pins are broken out: CAN/UART/I2C/SPI/4 GPIO. Maybe 20 usable total?
Also I'm not sure how you'd program it, if those pins are part of the ones that are broken out or not. They might have purposefully avoided letting you do this.

https://www.st.com/content/ccc/resource/technical/document/user_manual/group1/00/14/17/68/0f/01/48/01/DM00555046/files/DM00555046.pdf/jcr:content/translations/en.DM00555046.pdf

[lucazader]

You would likely have to program it using the inbuilt USB DFU interface.
And would likely have to figure out how to get it into the DFU mode to program. but once you do you can just use the cube programmer

[langwadt]

so it is basically cheaper than buying the MCU, could also be useful ad a small dev board if you don't need too many pins

It is a good value.
STM32F723 if anyone is wondering: https://www.st.com/en/microcontrollers-microprocessors/stm32f723ze.html
216MHz, 512kB flash, 256kB ram.

Yeah not so many pins are broken out: CAN/UART/I2C/SPI/4 GPIO. Maybe 20 usable total?
Also I'm not sure how you'd program it, if those pins are part of the ones that are broken out or not. They might have purposefully avoided letting you do this.

https://www.st.com/content/ccc/resource/technical/document/user_manual/group1/00/14/17/68/0f/01/48/01/DM00555046/files/DM00555046.pdf/jcr:content/translations/en.DM00555046.pdf

it doesn't mention what the four pin connector cn3 is for, maybe it is swd

[aandrew]

I'd love to know wtf was going through their heads screwing with the standard 2x5 0.050" connector. Now you need a stupid adapter board or custom cable to use it for all the existing systems. 

[TimCambridge]

There are lots of pinouts on ST-LINK-V3MODS but it has yet to appear except as a data sheet. Perhaps a guru can give us a timetable.

[pigrew]

it doesn't mention what the four pin connector cn3 is for, maybe it is swd

Yes, it's attached to the SWD port. One can also ask it use USB DFU in order to flash it.

See attached. If someone would draw up a schematic, that'd be great. I'm starting to wonder if the module could be used as a high-speed GPIB adapter.

Here are a few pins, though this could have some typos. (PM me and I'll fix the table)

CN3-1	VDD
CN3-2	PA14 (SWCLK)
CN3-3	GND
CN3-4	PA13 (SWDIO)
CN4-1	GND
CN4-2	nRST
CN5-2	PB14	(USB DM)
CN5-3	PB15	(USB DP)
1	PB11	Bridge UART RX(1)
2	PD11	Bridge UART CTS
3	PD12	Bridge UART RTS
4	PH7	T_JTMS/T_SWDIO
5	PG5	GNDDetect(2)
6	PC7	T_JTDO/T_SWO(3)
7	PA9	Bridge SPI CLK
8	GND	GND
9	PA11	Bridge CAN RX(1)
10	PA12	Bridge CAN TX(4)
11	PC10	Bridge UART TX(4)
12	PG9	T_VCP_TX
13	PB3	T_JCLK/T_SWCLK	(SWO)
14	PB4	Bridge SPI NSS
15	PG14	T_VCP_RX
16	PB6	Bridge I2C SCL
17	PB9	Bridge I2C SDA
18	PE2	Bridge GPIO0
19	PE4	Bridge GPIO1
20	PE5	Bridge GPIO2
21	PE6	Bridge GPIO3
22	(LoadSW out)	Reserved(5)
23	PC1	Bridge SPI MISO
24	GND	GND
25	PC2	Bridge SPI MOSI
26	GND	GND
27	GND	GND
28	PA1,PF8	T_JTDI/NC(6)
29	GND	GND
30		T_VCC(7)
31	PA6	T_NRST
32	PA7	T_SW_DIR
	PA0	T_VCC (pin 30), divided down
Load_EN	PB0	(load_EN (w 10k pulldown)
OSC 25MHz	PH0 OSC-IN
(VBUS detect???)	PB1/ADC?	(Vsw divided by (4.7k+2.7k))
LD1_1	PA10	(through 330 ohm)
LD1_2	PA10	(through 330 ohm)
LD1_3	GND
LD1_4	VDD	3.3V
LD2		ST-Link fault	Load-switch Fault
LD3	5V/VBUS?	5V power + resistor

There are two ESDALC6V1W5 (marking C61) 6.1V Zener ESD devices near the JTAG connector.

There is also a STMPS2151 load-switch.

[TimCambridge]

See attached.

It looks as if all (or some?) decoupling caps are on the top. Is that OK (when done carefully)?

[Fire Doger]

See attached.

It looks as if all (or some?) decoupling caps are on the top. Is that OK (when done carefully)?

There is no difference on which layer they are.
The important is how far they are. Top far is equal bad to bottom far.
The difference is that at bottom you can place them directly under the pads.

Being carefull doesn't change physics laws.

In picture bellow the trace in circle has some inductance. Longer trace = more inductance.
It may be an issue, it may not. You will find it out at the end...
In this case it wasn't causing any issues (i guess they tested it a lot...), in your case same distance may cause glitches.
Closer is always better.

[pigrew]

It looks as if all (or some?) decoupling caps are on the top. Is that OK (when done carefully)?

It's done this way so that the entire module can be flat on the bottom and surface-mounted onto a larger board.

The GND pads are a ways away from the capacitors, but it's probably fine.

I've added a few more pins to the table I was writing up... still not complete. It looks like there is a load switch on the output to the target, and ESD protection for the JTAG pins.

[thm_w]

Yes, it's attached to the SWD port. One can also ask it use USB DFU in order to flash it.

Nice work.
Looks like PB1 would be the only ADC or DAC pin, otherwise nothing else is broken out.

[pigrew]

Yes, it's attached to the SWD port. One can also ask it use USB DFU in order to flash it.

Nice work.
Looks like PB1 would be the only ADC or DAC pin, otherwise nothing else is broken out.

You're right... not too many.

I don't have the board in front of me, but it looks like PB0 goes somewhere, as well as PA1, PA6 and PA7. I have a feeling that they go to the RGB LED, though... So, there are other ADC pins available, but I'm not sure if they are connected to one of the 32 module pads or not. My table is only about half complete, and it'd probably be better to just create a schematic since there are so few components on the board.

[EmBlocks]

@ frogblender

I'm using the STlinkV3 with a STM32H7 project and it is much faster than the old V2. I'm using my own GDB server https://github.com/EmBitz/EBlink. It's for me (almost) the same as with a J-link.

Also those new boards with integrated V3 like STM32G474 (Nucleo-64) are insane fast.

Only down-side: I also use those STlinkV2 for other vendors like Silabs and NXP but I don't get that working with the STlinkV3.

[SiliconWizard]

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

[lucazader]

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 recently manually compiled and installed it on my ubuntu machine and it works great.

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.

[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.