ST-LINK/V3 ?

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