STLINK V3 - without mass storage enabled.

[delli]

Per corporate policy, USB Mass Storage devices are DISABLED on our corporate laptops. Period, end of story. There is no means to get around it, these are the rules.

Is there a means to DISABLE the mass storage feature? I see this is available for the STLINK V2, but not for the V3. In my case, it is specifically for the STM32H743ZI Nucleo-144 board.

Effectively, this feature: 'DRAG-DROP' - requires mass storage - which - effectively is a USB thumb drive type device, which is sort of "outlawed" where I am.

I don't have a choice in this matter.

[S C]

Hello,

are you facing troubles on other interfaces (debug and Virtual Com Port) because of this forbidden mass storage interface ? Theoretically they should still work. But of course you will need debugging/programming tools to program the target in place of the drag&drop feature.

Properly disabling the mass storage interface on STLINK-V3 demo boards is foreseen but currently not in a short term plan (which means not before 2021).

Moreover (for information) I precise that the implementation on the ST-Link is not a real mass storage disk (no real file system behind); it's only a wrapper for write access of bin/hex files to STM32 target flash (without readback capability), and read commands are only accessing an hard-coded (non modifiable) virtual file system => there is no risk for virus infection in such a system.

[Tesla DeLorean]

It acts like a MSC, Windows doesn't really know or care that it's some Faux-FAT implementation

[delli]

>> are you facing troubles on other interfaces (debug and Virtual Com Port) because of this forbidden mass storage interface ?

Yes - The entire device is is blocked, nothing is usable - that is the way that the block functions.

If I run a Linux VM, and attach the device to the Linux VM - the security measure is not enforced - it is only enforce on the WINDOWS side. I need this to work on Windows.

This is a common policy that many companies have - some have turned this feature on because so many people are not working from home due to covid. I would suggest you ask your internal IT department about "thumb drive policy" - I bet you will learn that your IT group wants this enabled, but they where over-ruled because of the problems that this would cause. I also suggest you ask your field FAE types - if they have come across this problem with customers - I bet they have had that type of problem occur.

This link - talks about a version of ST LINK that disables the thumb drive

>> https://electronics.stackexchange.com/questions/287465/how-to-disable-usb-mass-storage-in-stlink-on-nucleo

>> In the recent STLinkUpgrade 3.3.0 I can see checkbox "Change Type" offering "Debug + Mass storage + VCP" or "Debug + VCP". Seems like the way to go.

When I connected the board, the STM32 IDE wanted to update the Firmware - this choice was was not given as an option, and I can't seem to find a selection like this, and I cannot find any means to disable or replace the software with some other version or other choice.

Am I missing something? Or was this option removed? Or does this require some special thing install that version of the STLINK software.

Another option would be to rebuild the STLINK V3 firmware with that feature disabled.

Is the source code to this available? Question: Is this just a "#define" that needs to be disabled?

[S C]

OK, I clearly understood that this policy also blocks the other ST-Link interfaces, which is something I discover. I'm wondering however if there is no possibility to only block the mass storage interface (=one USB interface) without blocking the whole device (=one USB port) ?

Disabling the mass storage interface on STLINK-V3 embedded version needs to generate a new firmware type, it will be a #define once done ... Then some tools will need to be updated also in order to correctly identify this new USB PID. We already made the job on ST-Link/V2-1, STLINK-V3SET and STLINK-V3MODS (V3 firmwares with bridge interface), but it's not an immediate process and it's now too late for the next delivery. Knowing your issue, we will try to anticipate the following one, I'm afraid that's the best we can do on our side

[blechleitner]

Hi,

while searching, I found this question and would like to ask about the actual state of this issue.

I have a similar issue with the STLINK-V3MINI. I am using the latest firmware update tool 3.3.4 within CubeIDE 1.5.1 and there is no choice of modes with or without mass storage. In the upper post, you wrote, it works for V2-1, V3SET and V3MODS. I got a V3SET and connected it to my system and there I get the check box for changin type. So basically, things are working and I can confirm this statement. But it does not work with the V3MINI's, we are using here. Isn't the V3MINI a similar version to V3MODS but with an extra connector and some interfacing parts? When will the V3MINI be supported in that aspect as well?

Thanks for clarification.

Best regards,

Bernhard

[anonymous.010621_2136]

Same issue here. We also need to disable mass storage on ST-Link V3.

In our IT environment the mass storage causes issues because every time when plugged in the endpoint protection pops up and scans the device because of security rules. You need to wait and confirm manually everytime you plug in the ST-Link. This is very annoying.

Please release an update as soon as possible so that we can disable mass storage in ST-Link V3 like we are used to do in ST-Link V2 and V2.1.

Thanks, Sven

[blechleitner]

BUMP!

Hi dear,

are there any news about that story? In 1.6.1, there is still no solution. It's now 8 month passed since the reply from a ST employee, telling us that a solution is in the queue. Maybe the member S C can check this again and give us some update.

Thanks,

Bernhard

[S C]

Hello,

The update has been published this week on https://my.st.com/content/my_st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-programmers/stsw-link007.html. The release note (rev26) should follow (I just checked it's still not visible on the web, but should be soon).

Sorry for the delay. Hope this will fix your issues

[MMatj.1]

Link do not work any more :( 
Do you have file to share still ? 

Update.
Find new link: https://www.st.com/en/development-tools/stsw-link007.html

 

[blechleitner]

Hi,

thanks a lot. I downloaded the file and pushed it to a test system. Went like a charm. Now I will do the necessary tests but it looks very promising.

Best regards,

Bernhard

[blechleitner]

Hi,

@ S C:

I did now some tests but I am not happy with the new version. Until today, I used CubeIDE 1.6.1 with STLinkUpgrade 3.3.5 and STLink Fiwmware V3J7M3. Everything worked so far except the mass storage issue. I integrated the new Upgrade Tool and the libs into CubeIDE and now I see Version 3.3.6 and did a FW upgrade on STLink to V3J8M3. Went ok and I can still debug (with mass storage mode enabled). Good so far.

In Device Manager, I see the "STLink Virtual COM Port", under "Drives" i see "STM Product USB Device" and "STM STLINK USB Device", under "Mobile Devices" the Device "STLINK_V3M" and under "USB Devices" I see "ST-Link Debug".

Now I did a further FW upgrade with V3J8M3 but disabled mass storage. The upgrade went ok but now the troubles start: If I start a debug session, CubeIDE shows a message box with the title "ST-LINK firmware verification", telling me "No ST-LINK detected! Please connect the ST-LINK and restart the debug session.". In Device Manager, the ST-LINK Virtual COM disappeared and therefore a general USB device appears. The PID changed from 0x374E to 0x3754. Under "Devices", the entry "STM STLINK USB Device" dissapeared as well (expected). Under "USB Devices" the entry "ST-Link Debug" remains visible but it's PID changed also from 0x374E to 0x3754.

In "STM32Debug+VCP" Mode (means without mass storage), In CubeIDE -> Debug Configurations -> Debugger -> Interface, it is possible to scan for the debugger. It's serial number is shown. So a general access is possible but no debugging session. If I go back to the FW V3J8M3 but with enabled mass storage, I can start the debugger again. Fully reproducible.

Is it possible that CubeIDE/Debugger simply does not recognize the new (?) PID? Is there anything else we can do or do we have to wait for a new CubeIDE as well? Do we also need a new GDB Server? By the way, the same is with CubeProgrammer.

Thanks in advance

Bernhard

[S C]

The device USB PID changed to 0x3754 because of the new set of interfaces. The debug interface GUID remains the same so 'theoretically' the debug should work smoothly on tools not checking against the USB PID. Unfortunately tools are filtering on the USB PID for other constraints, which explains the failure. Consequently I'm afraid you will need to wait for the update of such tools before debugging with the USB device 0x3754. Concerned teams have been notified however I don't have myself the overall vision of deliveries. So to handle with care: IAR should provide a new version this month, Keil, CubeIDE and CubeProgrammer in June.