STLINK V3 and USB cables

[SiliconWizard]

I finally got around to evaluating the STM32U5 and got a Nucleo dev board for that purpose.
It embeds a STLINK V3 programmer. (For the record, I only use third-party DAP or FTDI-based SWD adapters for STM32 MCUs and haven't used a STLINK programmer in years - last I used was a V2 and didn't remember having any issue with it.)

I thought it was DOA, but it was just the USB cable. I had tried several USB cables that otherwise all work fine with all of my other USB HS devices. But, the STLINK V3 on the Nucleo didn't like any of these cables. It seems to be very, very picky. I found a number of threads on ST's forums about it. I can confirm. It worked only with *one* of my cables. I must mention that I'm talking about USB-C to USB-A cables here (the Nucleo has a USB-C connector). After that, I also tried two different USB-C to USB-C (but obviously on a different machine that has native USB-C) cables, and both worked fine.

I think that may good to know if anyone runs into the same problem.

Now to the technical aspects of it: I wonder what's the root cause of this pickiness (as again all the cables that failed with it work perfectly fine in USB 2.0 HS with all of my other devices). The observable behavior with cables it doesn't "like" is that it's as though the data lines where not even connected: there is no visible attempt of enumeration (which you can easily track on Linux). Odd.

So is that a particularly poor routing job on the Nucleo board, or could it be that the USB PHY on the MCU that implements the STLINK V3, a STM32F723, is crap? I'd be curious to hear about experiences with the STM32F723 and USB HS. Could be more interesting than merely a problem with a given dev board.

[ajb]

Can you measure the voltage on the CC pins at the dev board for both good and bad cables?  Devices are supposed to have pulldowns on CC1 and CC2 so the downstream facing port can detect them, but I think the specific voltage at the CC pins is also used to help determine device roles, IIRC.  Certain kinds of USB C to 'legacy' adapters/cables are required to have CC resistors for that reason, but I suspect that a lot of them just don't.  So maybe the dev board is looking for a specific voltage before it starts enumeration and not seeing it on those cables?  A C device should probably allow enumeration if it detects VBUS even if the correct CC voltage isn't present, specifically because of cheap cables like that, but maybe the firmware developers didn't think about that 

The only other thing that comes to mind is that the whole design is electrically marginal for some other reasons, but that wouldn't normally prevent the device from even enumerating.

[SiliconWizard]

Given the symptoms, I second your doubt about the CCx signals, possibly being handled by the STLINK V3 while being ignored by most USB devices that just pull down those pins with 5k1 resistors, to advertise as a sink, and do nothing else.

Not sure I see the point of reading those voltages on the STLINK V3, unless it can also act as a host? I didn't think so, but maybe. Or maybe they just implemented USB PD (even if that's not very useful for this device, although it may be part of its features?) and indeed that can get very problematic depending on the cables you use, especially with USB-C to USB-A cables.

So, that's a good point and I'm going to have a look at the schematic and go from there. (The schematic of the embedded STLINK V3 is actually given in the schematic of the Nucleo board.)

[ataradov]

What board it is exactly? The one that comes up in the search uses Micro-USB on the debugger side and Type-C on the target side.

In general, the only time I has issues with USB HS was with silicone cables, which are nice and flexible, but have really poor performance because of that. And "thin" cables you sometimes get with consumer electronics are not great either. They are oriented towards charging more than data transfer.

[SiliconWizard]

What board it is exactly? The one that comes up in the search uses Micro-USB on the debugger side and Type-C on the target side.

In general, the only time I has issues with USB HS was with silicone cables, which are nice and flexible, but have really poor performance because of that. And "thin" cables you sometimes get with consumer electronics are not great either. They are oriented towards charging more than data transfer.

The newer Nucleo's have USB-C on both sides and embed a STLINK V3, which is the latest STLINK with a STM32F7 (while IIRC the old ones had a STLINK V2 with a STM32F103?), making the STLINK part of them often much more expensive than the rest of the board!

It is definitely a CCx pins problem. I looked at the schematic, and indeed, while CC1/2 are pulled down with 5k1 resistors, the lines go to 2 ADC pins of the STM32F7 via a RC filter. So they definitely read the voltages. I think I now understand what they are doing with that. That's the simplest way (not requiring a dedicated USB-PD chip, or embedded USB-PD IP) of determining how much current a USB device can draw from the host - assuming it's connected to a true USB-C source on the other end, or at least using proper USB-C to USB-A cables, which many are not.

Indeed, the host (source), depending on how much current it can source, will pull-up CC with a different resistor value, then yielding a specific voltage range on the CC pin when connected to a sink. I suppose they found it interesting, and cheap enough, to determine how much current the STLINK programmer could draw from the host, although that really makes sense only if you intend to draw more than the max. 500 mA that you're guaranteed to get with no special measure, and I don't know what a STLINK would use more current for, but maybe that's the plus they offer with the V3 for powering "hungry" targets.

So, that makes the STLINK V3 unusable if you don't have the right cables. A not so good oversight from ST.
Now, I saw that there was a firmware update for the STLINK V3 and that the version that's on my board is oldish (2022), so I'm going to try and update it, and see if they have maybe fixed this issue in newer firmware. I'll post the results.

[ataradov]

There are a couple options here. Either board/MCU indeed needs more than 500 mA. In that case it should work only if it can identify the correct host. Or expect supplementary power from the external supply. This is what recent Microchip kits do. Except they don't even bother with USB power and just reqire an external supply.

Otherwise they should assume that 500 mA is the max they can get if they get 0V on CCx pins. USB-A connectors don't have this signal, so it can't work with any USB-A cable. Sounds like something they would notice.

I don't think this is an oversight, it is likely intentional and may be documented in the board user guide.

There are not C-to-C cables that don't have a CC wire. Even the cheapest ones usually have it. 

What's the board part number?

[NorthGuy]

The USB type A to type C cable is supposed to have 56k resistor inside indicating that 500 mA is available. You should be able to measure this between one of the CCs and VBus. Stronger resistors would indicate higher current ability and must not be installed in A-to-C cable.

So, if STLINK checks for voltage on CC and uses it as a guidance, then A-to-C cables that didn't work are actually the good ones. And the one that was working is the bad one - not meeting USB specs.

[ataradov]

There is a good chance that it seen 500 mA and decided that it was not enough. If they felt the need to actively sense this, they must know that the board needs more and refused to power up the device.

Assuming that the board in question is STM32U5 Nucleo-64 board (MB1841), then the document mentions that they try to follow the USB spec:

The Nucleo-64 board and its shield can be powered from the STLINK-V3EC USB connector (CN1), but only the STLINK-V3EC circuit is powered before USB enumeration because the host PC only provides 100 mA to the board at that time. During the USB enumeration, the Nucleo-64 board requests 500 mA power from the host PC.
• If the host can provide the required power, the U5 power switch is enabled, the green LED (LD3) is turned ON, and the Nucleo-64 board and its shield can consume up to 500 mA.
• If the host is not able to provide the requested current, the enumeration fails. the U5 power switch remains OFF and the MCU part including the extension board is not powered. As a consequence, the green LED (LD3) remains OFF. In this case, it is recommended to use an external 5 V power source.

So, they don't assume that host can provide more than 100 mA before the enumeration. It is possible that this causes additional issues, since nobody in history of USB ever did that.

And they have hardware current limiter.  This thing is very over-engineered for no reason.

[fchk]

So, that makes the STLINK V3 unusable if you don't have the right cables. A not so good oversight from ST.

Your STLink V3 is part of the Nucleo board? Then the title is misleading.

When reading "STLink V3" i think of an STLINKV3-MINI
https://www.st.com/en/development-tools/stlink-v3mini.html
or an STLINKV3-MINIE
https://www.st.com/en/development-tools/stlink-v3minie.html

The difference between these two is that the Mini has got Micro-USB-B and the MiniE has USB-C. Both work fine - never had any USB problems. But the USB only powers the STM32F723, never the target. That is the key difference.

Please power your Nucleo board externally and check if your problems go away then.

[ataradov]

It is STLINK-V3EC - the onboard version that has additional power controls for the target device.

[coromonadalix]

i have a minie   never had any problems with usb-c cables brands ?


normally  on nucleo  boards  you have to remove jumpers to isolate  data lines between the st link and  mcu   at least 2 jumpers

as mentioned    it should not be able to power target    it does need to sense target voltage / supply to work

that would be the schematic of your board
https://www.st.com/resource/en/schematic_pack/mb1841-u545req-d01-schematic.pdf

[SiliconWizard]

There is a good chance that it seen 500 mA and decided that it was not enough. If they felt the need to actively sense this, they must know that the board needs more and refused to power up the device.

Assuming that the board in question is STM32U5 Nucleo-64 board (MB1841), then the document mentions that they try to follow the USB spec:

The Nucleo-64 board and its shield can be powered from the STLINK-V3EC USB connector (CN1), but only the STLINK-V3EC circuit is powered before USB enumeration because the host PC only provides 100 mA to the board at that time. During the USB enumeration, the Nucleo-64 board requests 500 mA power from the host PC.
• If the host can provide the required power, the U5 power switch is enabled, the green LED (LD3) is turned ON, and the Nucleo-64 board and its shield can consume up to 500 mA.
• If the host is not able to provide the requested current, the enumeration fails. the U5 power switch remains OFF and the MCU part including the extension board is not powered. As a consequence, the green LED (LD3) remains OFF. In this case, it is recommended to use an external 5 V power source.

So, they don't assume that host can provide more than 100 mA before the enumeration. It is possible that this causes additional issues, since nobody in history of USB ever did that.

And they have hardware current limiter.  This thing is very over-engineered for no reason.

Yes, it is somewhat overengineered, but I'm assuming the base design is the same among all STLINK V3 models that have a USB-C connection. I see no reason why not - the "overengineered" versions would  otherwise be more the standalone products than the ones embedded in Nucleo boards, which, as I said, make up for most of the cost of the board actually.

No, there is zero reason it would ever need to draw more than 500 mA under normal use. The only reason it could need more is again to power more power hungry targets, but that should be a choice of the user, not something strictly enforced. Certainly, the Nucleo-64 boards don't need any more than this unless you power extra stuff through them. The STM32F7 itself and surrounding components only draw a fraction of this.

The firmware is the same for all STLINK V3 with a STM32F723 as far as I can tell, so they must all do the same thing as long as they have USB-C (which I didn't know not all do for some odd reason).

This is a questionable decision anyway. The problem, once "debugged", is *not* that the board would require getting more than 500 mA. This isn't it. The problem is that it absolutely requires cables with a pull-up resistor if using USB-C to USB-A cables, and it turns out that there are many out there that don't, and that work fine with most devices out there. I happen to have plenty of those and only a couple cables that have pull-up resistors.

If the pull-up resistor is not in the cable, the voltage will just read ~0V, which I'm assuming now the firmware on the STLINK V3 (those again with USB-C since this is strictly a USB-C related issue) considers "faulty" and doesn't initialize the USB controller at all.

There are a few threads about it on ST forums, and I consider their answers to be, at least, incomplete and not explaining what the core of the problem is. They just say things like "use better cables because this device is USB HS and needs better quality cables", somehow implying that it would be a signal integrity issue, while it's absolutely not. Whether those cables are conforming or not is another story - they are probably not, but I guarantee you that you probably have as many of them as I do.

So, if anyone runs into this, you'll know what it is and you'll find here the reason that you won't find elsewhere (at least that I could find).

For people designing USB-C devices, I recommend not doing the same thing, unless you actually need for sure more than 500 mA right from the start.
Handle the current limit only after the device has enumerated and give users a fallback mode that only uses max. 500 mA. Otherwise you're going to have tons of technical support to do for no reason. Just my 2 cents.

[thm_w]

Kind of hard to blame them for designing around the spec. Maybe update the thread with the actual issue at hand you found.

Here is a random sampling of old cables: https://www.pcworld.com/article/1063892/we-tested-43-old-usb-c-to-usb-a-cables-1-was-great-10-were-dangerous.html

[SiliconWizard]

Yes, turns out I have a bunch of USB-C to USB-A cables that work fine for most uses but have this absent pull-up issue. I'm not even 100% sure this isn't compliant, although that sounds likely. I'll re-read the USB-C specs, these are pretty heavy.
Currently, the only cables that are fully compliant that I have are UGreen cables, which are nicely made but the cables tend to be a bit stiff, so I generally prefer using more flexible cables on the bench... I'll probably consider getting rid of a number of them.

That said, I still think handling CCx voltages this way is not the best idea, and that certainly is *not required* for a USB-C compliant *device* (just the two 5k1 pull-downs, as a minimum, are). Indeed, if the device enumerates properly, then it is guaranteed to get at least 500 mA. If your device then has operating modes that may require more than 500 mA, you can then read CCx voltages and determine which of your operating modes you will allow. But instead, they decided to read the CCx voltages first thing when the MCU starts and if they don't look in the normal ranges, it just doesn't enable the USB controller at all.

I'm standing by my position that this isn't the greatest design idea you can have for keeping your customers happy, but this can also be defended in that one may consider that if the CCx voltages are not in the accepted ranges, that may mean that whatever it's connected to is not functioning properly and that it may be safer to just not even enable the USB controller.

Again, beyond this particular case, I think that's an interesting point to think about when you design a device with USB-C connection, because while the cables themselves may not be compliant, it is definitely compliant to design a device that just has two pull-downs and does not read the CCx voltages if you don't need more than 500 mA.

[peter-h]

The cases where I found USB cables are critical (or just their length is) is where there are "wrong" PCB tracks leading to the connector(s). Then the effect of the impedance mismatch is influenced by the cable properties.

I use the STLINK V3 all the time but I use pricey cables. Had too bad cheap USB cables; gone in the bin.

I am sure the V3 does not draw 500mA. There would be many problems with laptops, some of which have an actual overcurrent trip.

[NorthGuy]

Currently, the only cables that are fully compliant that I have are UGreen cables, which are nicely made but the cables tend to be a bit stiff, so I generally prefer using more flexible cables on the bench... I'll probably consider getting rid of a number of them.

A few years back I analyzed dozens of A-to-C cables - some were stunningly beautiful, some were unbelievably flexible, but UGREEN was the only cable that had proper shielding. This is because the majority of cables are designed for charging. They have PCBs inside to support fast charging. But nobody worries about data.

[ataradov]

If your device then has operating modes that may require more than 500 mA, you can then read CCx voltages and determine which of your operating modes you will allow.

In their case they don't know how much the target will need. They have a separate over current protection IC, which they configure based on the discovered maximum current. The board itself will never consume even 500 mA. But the attached external devices might.

It is a fine design if this is the design goal, but I personally would put jumper than bypasses all of this and configures OCP IC for the max current.

[SiliconWizard]

If your device then has operating modes that may require more than 500 mA, you can then read CCx voltages and determine which of your operating modes you will allow.

In their case they don't know how much the target will need. They have a separate over current protection IC, which they configure based on the discovered maximum current. The board itself will never consume even 500 mA. But the attached external devices might.

It is a fine design if this is the design goal, but I personally would put jumper than bypasses all of this and configures OCP IC for the max current.

But the point is that they could just have limited the current to 500 mA by default. Precisely, they configure the current limiter based on the discovered max current. So, by default, they are guaranted 500 mA. (And from your argument, if they discover 900 mA but the target may need more, should they also bail out? Of course not.)

It's just that they decided to not even enable the USB controller (so not even attempt to be enumerated) if there's no CC pull-up (and thus, they just measure near 0 V), making the device appear "dead beef". That's the point which is questionable, and nor the manual nor what they say on their KB/forums is really helpful with that.

Granted that's a design choice that, as I said, could be defended: it's a USB-C connection and thus the CC lines are supposed to behave as the standard says. But that's not so good for users of USB-C to USB-A cables (which are still common, especially in a lab context). So, the question is, would you guys design it this way?

I haven't looked at all their offering in terms of STLINK V3 though, they have several variants and not all are USB-C. And this variant I have is embedded in a Nucleo board, but I have no reason to think the design is any different from the standalone STLINK V3 (with USB-C) in that regard, if they have one. I know they also embed a STLINK V3 with micro-USB on some other Nucleo boards, so obviously in that case you wouldn't run into that.

Just an interesting design question though, considering USB-C is pretty complex, tries to do it all, and the number of possible configurations is almost endless, between USB-C to USB-C cables (that come in many variants), USB-C to USB-A cables (ditto) and hosts, which also do only support a subset of USB-C, each a bit different. It's a pretty complex thing once you get beyond the basics (which is using USB-C as you used USB-B and only the D+/D- pair).

[asmi]

I am sure the V3 does not draw 500mA. There would be many problems with laptops, some of which have an actual overcurrent trip.

If my memory serves me, USB 3 requires providing 900 mA of current per downstream port. And it's been a while since I've seen laptops with USB 2 ports.

[SiliconWizard]

I am sure the V3 does not draw 500mA. There would be many problems with laptops, some of which have an actual overcurrent trip.

If my memory serves me, USB 3 requires providing 900 mA of current per downstream port. And it's been a while since I've seen laptops with USB 2 ports.

Yes, and that's the minimum that it must be able to provide. But: if the host actually enforces a current limit based on enumeration info (which is rarely if ever the case on desktop computers, and more common, although to varying degrees, on laptops), then a device is not supposed to draw that much current unless it has "asked" for it during enumeration. And for that, strictly speaking, the USB descriptor must be a SuperSpeed descriptor which gives the max current in units of 8 mA, as opposed to units of 2 mA for the previous descriptor formats (and since it's a single byte...) I don't think you can ask for more than 500 mA in HS mode (although I would have to check back in the specs) even when connected to a USB 3 host.

A compliant device should in theory not draw more than 100 mA until it has enumerated, and no more than what it asked for in the corresponding descriptor once it has enumerated. In practice, many devices are not fully compliant and still work with most hosts. Even laptops rarely (or never?) set the current limit to whatever the descriptor says. They do have maybe 2 to 3 limits (100 mA, 500 mA & 900 mA) and that's usually it. The 100 mA before enumeration is rarely enforced. But the max current in suspend mode may be (2.5 mA IIRC).

Anyway, that's again not the point here as this particular device uses specificities of USB-C in a way that, while correct from the perspective of the USB-C spec, can be questioned if they want their consumers to be able to use it on USB-A ports with a USB-C to USB-A cable (which, like even USB-C to USB-C cables, come in many variants). Other than that, the STLINK V3 (USB-C) works fine and for the record, its own power draw is ~70 mA on average. I was a bit surprised (was expecting less), but looking at the DS for the STM32F7 it uses, that's in line with what the MCU draws, and not even at its max clock frequency.

[asmi]

A compliant device should in theory not draw more than 100 mA until it has enumerated, and no more than what it asked for in the corresponding descriptor once it has enumerated. In practice, many devices are not fully compliant and still work with most hosts. Even laptops rarely (or never?) set the current limit to whatever the descriptor says. They do have maybe 2 to 3 limits (100 mA, 500 mA & 900 mA) and that's usually it. The 100 mA before enumeration is rarely enforced. But the max current in suspend mode may be (2.5 mA IIRC).

I've seen quite a number of USB host devices' schematics, but I can't remember a single instance where it would actually be physically possible to control the current limit. In vast majority cases there are current limit switches like MIC2095/2098 which have a fixed current limit of 500 and 900 mA respectively.

Anyway, that's again not the point here as this particular device uses specificities of USB-C in a way that, while correct from the perspective of the USB-C spec, can be questioned if they want their consumers to be able to use it on USB-A ports with a USB-C to USB-A cable (which, like even USB-C to USB-C cables, come in many variants). Other than that, the STLINK V3 (USB-C) works fine and for the record, its own power draw is ~70 mA on average. I was a bit surprised (was expecting less), but looking at the DS for the STM32F7 it uses, that's in line with what the MCU draws, and not even at its max clock frequency.

Yeah, unfortunately USB has become a victim of it's own success, which is why there are so many possible configurations, and this forces users to have a bunch of cables which are compatible with different use-cases.