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.
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.
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.
At least the cobbling together of your programmer is consistent with the rest of the STM toolchain.
Is the V3 protocol compatible with the V2?
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.
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.
Greetings,
As far as cost goes, as of about 5 mins ago, you could get a STLINK-V3MINI from Digi-Key for $10.37.
STLINKV3MINIAnd Mouser has them for $9.75..
STLINK-V3MINIIt looks like it does almost everything the big one does. Except take the adapter boards..
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.
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
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
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.
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.
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.
See attached.
It looks as if all (or some?) decoupling caps are on the top. Is that OK (when done carefully)?
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.
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.
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.
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.
@ 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.
If you want to use OpenOCD, AFAIR, it has support for the V2 but not (yet?) for the V3.
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.
