Unable to connect (& hence flash the firmware) the STM32-Cube-Programmer with STM32-target-board in USB-DFU-mode if loaded firmware is read-protected.

[nirav soni]

1) I am able to connect the STM32-Cube-Programmer in USB-DFU-mode if existing or loaded firmware in to STM32-target-board is not read-protected.

Image-1: Able to connect with target board

Image-2: Able to load firmware in to target board

2) I am not able to connect the STM32-Cube-Programmer in USB-DFU-mode if existing or loaded firmware in to STM32-target-board is read-protected.

Image-3: Not even able to connect with target board

In this case I am keep getting the DFU connection error,

How to resolve this application bug.

Programmer seems to be not professionally viable,

Has anyone in community found resolution to this application bug.

Can anybody in STM comment?

[Uwe Bonnes]

Can you try another dfu program, as Tormod Volden dfu-util? Does "dfu-uti -l" list the the device when in DFU mode and protected? Then you can erase and rewrite the option with dfu-util.

[LPosl]

I have exactly the same case with STM32F042 and current STM32CubeProgrammer tool. I'm new to STM32 - my first design now. Tried on 2 PCs. I wasted time on trying a few tools, DfuSE does not see anything, dfu-utl see the chip but I had no clue how to remove the lock. Finally I went to CubeProgrammer folder, and toticed that there is command line version of the tool which I run with following command:

STM32_Programmer_CLI.exe -C port:usb1 -rdu

and got device back in read Level 0 protection

[nirav soni]

Yes, That's correct, STM32 uC Read out protection can be disabled in usb + dfu mode with command line interface​ only using

STM32_Programmer_CLI.exe.

Thanks for the confirmation.

[nirav soni]

I have observed this issue (Unable to connect (& hence flash the firmware) the STM32-Cube-Programmer with STM32-target-board in USB-DFU-mode if loaded firmware is read-protected) on STM32CubeProgrammer API v2.1.0

Whether above mentioned bug is resolved in STM32CubeProgrammer API v2.4.0 in the current or latest application software setup for STM32-Cube-Programmer ???

[Beachmiles]

There appears to be a bug in stm32cubeprogrammer when trying to connect to the usb bootloader when connecting directly to the onboard USB 2 or USB 3 ports for about half of the stm32f469 micros I've tested with in Windows 10 at least.

If I use a usb 3 hub in between the stm32 device and the onboard USB ports the connection works! Some USB 2 hubs work and some dont so something is very wacky. I have verified this behaviour with a windows laptop, 2 windows desktops, and multiple windows 10 tablets.

The other half of the stm32f469 devices work just fine without the hub connecting directly to the onboard USB ports.

So quickfix is to use a usb 3 hub instead of the onboard Usb ports.

[SBone.3]

I'm having the same issue, @nirav soni​ and @Beachmiles​ are reporting, and I can confirm what @Beachmiles​ said: The same USB DFU device, on the same PC behaves differently in the following scenarios:

• plugged through an USB HUB: The STM32CubeProgrammer detects the STM32 BOOTLOADER device and is able to connect properly, performing FW update
• plugged directly in the USB port of the PC: the STM32CubeProgrammer cannot connect to the device since is detected as "read protected"

This is a serious issue for our company, since we cannot perform FW update of our devices on the field if the user does not have an USB HUB with is PC.

Do you have an update on this topic?

Thank you!

[Pavel A.]

Does the PC run Windows? Can you try a Linux PC instead? I have seen similar behavior with other less than standard USB devices. Windows is very demanding. Linux seems to behave more relaxed. A good hub can help (maybe adds a delay or smth like that).

Give USB hubs to your techs.

[SBone.3]

Thanks for your suggestions, unfortunately we cannot use a Linux PC neither give hubs to hour techs, since the update is done by the customers themselves with their own windows pc, using a custom tool we developed, which relies on the DFU USB drivers provided by ST.

Upon our tool installation, we run "STM32Bootloader.bat" provided with the STM32CubeProgrammer bundle, which installs the needed drivers into the user PC.

Since the connection/update procedure fails with both our tool and STM32CubeProgrammer application, i fear that the issue is inside the provided USB drivers.

Would be nice to have a feedback by ST upon this topic.

Thanks!

[JKolj.1]

We have been struggling with this issue quite a bit lately, and spent hours and hours debugging it. I thought that the issue was my USB layout. STM32CubeProgrammer connection sometimes worked and sometimes didn't with my W10 ThinkPad P15 laptop. Same thing with my coworker's laptop. The USB 3.0 hub trick works 100%. Thank you! It would really be nice to get some input from ST about this.