STM32CubeProgrammer (MCUs)

Product/Tool: STM32CubeProgrammer CLI v2.19.0Target MCU: STM32U385RG-Q (Nucleo-U385RG-Q board)Connection: SWD, mode=UR (Under Reset)TZEN: 0 (non-secure)================================================================================SUMMARY================================================================================We are unable to program a full 16-byte OTP row using STM32_Programmer_CLI.Only the first double-word (8 bytes) of a row can be written. Any attempt toprogram the second double-word of the same row fails silently (word remains0xFFFFFFFF) or is rejected by the flash controller, even though the row shouldnot be locked until both double-words are programmed.Per the reference manual, the OTP lock granularity is one 16-byte row(2 double-words). We expect to be able to program both double-words within arow independently (each in a single operation), provided neither has beenwritten previously. However in practice, programming the first double-wordappears to immediately lock the

I am trying to do multidrop with STM32WL5MOC and STM32U031. I have some issues:[1] When WL5MOC is the only active MCU in the circuit (U0 is not powered on) I cannot connect M4 core using TargetSel=0x04970041 option:I can connect to M0+ core using tagetsel (STM32_Programmer_CLI -c port=swd TargetSel=0x04970041 ap=1 mode=hotplug)If I try the same with ap=0, CLI cannot connect to M4 core and retires with ap=1 and then connects M0+ core againThere is no issue when not using targetsel option and U0 is disconnected. I can connect both WL5 cores with ap=0 and ap=1 options.[2] If I power on U0 and try multidrop, I cannot connect any of the cores of WL5:I can connect U0 with targetsel option(STM32_Programmer_CLI -c port=swd TargetSel=0x04590041 ap=0 mode=hotplug).. At first CLI cannot connect with ap=0 and retries with ap=1 and then connects.Interestginly If I try ap=1 directly, it cannot connect to U0 (STM32_Programmer_CLI -c port=swd TargetSel=0x04590041 ap=0 mode=hotplug)Am I missi

I have created a firmware for a STM32L010F4Px microcontroller.I was able to Connect and Download Firmware by using ST-LINK V2.For some reason, I can't connect to the MCU at the moment by using CubeProgrammer + ST-LINK V2.Instead, I can connect/debug my microcontroller by using a SEGGER J-Link Ultra+ + J-Flash tool.The log from CubeProgrammer doesn't give me much details:13:28:34 : UR connection mode is defined with the HWrst reset mode13:28:34 : ST-LINK SN : 37FF71064E573436D2C1144313:28:34 : ST-LINK FW : V2J47S713:28:34 : Board : --13:28:34 : Voltage : 3.28V13:28:34 : Error: Unable to get core ID13:28:34 : Error: No STM32 target found! If your product embeds Debug Authentication, please perform a discovery using Debug Authentication

Hello everyone,I'm using STM32CubeIDE 2.1.0 and STM32CubeProgrammer on Ubuntu 24.04.4 LTS.Yesterday I was able to flash my firmware to an module based on the STM32H755 MCU via ST-LINK using the following settings:Port: SWDMode: NormalReset mode: Software resetEverything worked fine. Today I made some modifications to the firmware, but when I tried to connect again, I got this error:Error: No STM32 target found! If your product embeds Debug Authentication, please perform a discovery using Debug AuthenticationThings I have already tried (none worked):Changing Mode to "Under Reset"Changing Reset Mode to "Hardware reset" and "Core reset"Holding the reset button while clicking connectTesting with a different ST-LINK programmerTesting with a different board (same MCU)Here is what st-info --probe returns:Failed to enter SWD mode Found 1 stlink programmers version: V3J15 serial: 004100223235511237333439 flash: 0 (pagesize: 0) sram: 0 chipid: 0x000 dev-type: unknownThe ST-LINK i

Hi When I using STM32CubeProgrammer 2.22 GUI and try to control option byte, the page can't display.while CLI can read option bypte. 

It seems like it's been over a year since reports surfaced that the ST-Link interface isn't working on Snapdragons.Are there still no ST-Link interface drivers available for Snapdragon CPUs?

Hi everyone, I am facing an issue with an STM32U5 regarding the entry into STOP3 mode after a production programming cycle using the STM32CubeProgrammer CLI. I use a .cmd script to flash the device. In the script, I use the -c port=swd dLPM mode=UR flags to ensure the first connection during the multi-step programming of several binaries. At the end of the script, I perform a software reset via -c port=swd dLPM -rst. After the script finishes and I unplug the ST-Link, the microcontroller fails to enter STOP3 mode (current consumption remains high, in the mA range). I noticed that if I manually connect with the STM32CubeProgrammer GUI without the "Debug in Low Power Mode" (dLPM) option enabled, perform a software reset, and then disconnect the JTAG/SWD, the device enters STOP3 correctly. It seems that the dLPM flag used during the CLI session is "sticky": it sets the DBG_STOP and DBG_STANDBY bits in the DBGMCU_CR register, and these bits persist even after the programmer is physically d

Hi there! First of all, thank you for taking the time to read this!!! Any input is welcome. I'm working on a project with a Nucleo-H563ZI board, and did something quite dumb: went and set the PRODUCT_STATE to CLOSED from within some dummy FW, and now I'm stuck. I can see the FW is running (LED task is blinking), but now I can't seem to access the device through Debug Authentication to bring it back to OPEN. When I click on Full Regression STM32CubeProgrammer complains about "Password file not found" Which is more than logical because I did not provide one (you can see on the first image). Since I didn't set any password, I tried passing in an empty file created by running: touch empty.bin And then, it complains with: Is there some way to run a regression? Or do I now have a pretty brick? Thanks in advance!!

STM32H523CET6 stuck in PRODUCT_STATE=0x17 (PROVISIONING)TZEN=0xC3 (disabled), DA not configured, BOOT_UBE=0xB4CubeProgrammer v2.22, all regression attempts faildebugauth=2 returns: "unable to boot on RSS_DA or is in OPEN mode"After this function it bricked:void LockCode(void) { FLASH_OBProgramInitTypeDef OBInit = {0}; HAL_FLASH_Unlock(); HAL_FLASH_OB_Unlock(); HAL_FLASHEx_OBGetConfig(&OBInit); if (OBInit.ProductState == OB_PROD_STATE_OPEN) { OBInit.OptionType = OPTIONBYTE_PROD_STATE; OBInit.ProductState = OB_PROD_STATE_PROVISIONING; HAL_FLASHEx_OBProgram(&OBInit); HAL_FLASH_OB_Launch(); } HAL_FLASH_OB_Lock(); HAL_FLASH_Lock(); }Edited to apply source code formatting - please see How to insert source code for future reference.

Hi,I'm having trouble getting my ST-Link V2 dongle to be recognized by Cube Programmer. It is recognized by Windows 10 in the device manager, I have been able to update the firmware, and I can get it to load in STM32 ST-Link Utility, but that program doesn't support the .elf file format I need.When I launch Cube Programmer, it does recognize something as shown by the voltage and the firmware (image attached), but when I click the refresh button next to the serial number it says "No ST-Link detected."I've read from others that there are a lot knockoffs of these dongles floating around that don't work anymore. That might be the problem with mine (this is the second one I've bought and tried). Can anyone point me to a good source to buy a legit one? In the products page, I've only seen the bigger ST-Link V2 unit and the smaller USB-C V3 unit, but not the V2 Dongle.I'm trying to flash a board for an Atari 2600 homebrew game I made and I attached a diagram of what the instructions show

I'm looking at setting the RDP Level to Level 1 for an STM32F103 and I don't see the AA BB CC type stuff like in the current manual. Is this something that STM32CubeProgrammer is doing on purpose for this MCU?  I definitely don't want to enable Level 2 by accident and brick my chip.  Here is a screenshot of what I see:Is it safe to check this? 

I can't seem to read the OTP bits on the stm32N6 with any of my boards with 2.22 of the stm32CubeProgrammer.   But i can on version 2.21 Everything else works fine with the chip. 

I am using a stm32 F103RCT6 mcu. It has 256 Kb of flash memory. But when i connect it to cube programmer, it shows there are 256 sectors of 2K size which equates to 512 Kb flash.  I was even able to go to that last page and write data to it. so is the linker script generated by HAL wrong?    

Trying to program the option bytes I get the error message shown below. Can someone tell me what is wrong? I have tried with and without the displ and I have also tried with only one option byte at the time.C:\Temp\BMSM-18>"C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe" -c port=SWD -ob TZEN=B4 SECWM1_STRT=0x0 SECWM1_END=0x0 SECWM2_STRT=0x1f SECWM2_END=0x0 displ-------------------------------------------------------------------STM32CubeProgrammer v2.22.0-------------------------------------------------------------------ST-LINK SN : 003F00383234511537333934ST-LINK FW : V3J15M7Board : STLINK-V3MINIEVoltage : 3.29VSWD freq : 8000 KHzConnect mode: NormalReset mode : Software resetDevice ID : 0x478Revision ID : --Device name : STM32H533/523NVM size : 512 KBytesDevice type : MCUDevice CPU : Cortex-M33BL Version : 0xE2SFSP Version: v1.2.0Debug in Low Power mode enabledError: Wrong command -ob tzen=b4 secwm1_strt=0x0 secwm1_end=0x0 secwm2_strt

I was trying to implement emulated EEPROM and I think I set the EEPROM page area right into the critical option bytes area. Notably, this didn't happen until I added the actual eeprom_emul.c and flash_interface.c files into the cmake configuration, compiled and flashed the program once. This obviously makes a call to "HAL_FLASH_UNLOCK()" so I think it's pretty messed up. Either way, after this, I could not flash the chip beyond 0x80000050, additionally, it would instantly lock up on boot. I believe my Option Bytes were also grenaded.  PCROP_RDP turned itself on, ESE turned itself on and the rest I am unsure of changes. Either way, I managed to turn off RCROP_RDP by setting RDP to 1 and then to 0. After this, flashing the chip, fills every line with the same repeating nonsense bytes. So I think write protection is disabled, but it's still uploading nonsesen. Notably, trying to hit "full chip erase" does not work, and just hangs. Now ESE remains checked. When trying to uncheck

CubeProgrammer 2.22.0 under MacOS 26.4.1 is not able to connect to my NUCLEO-G431, with the log window showing:ST-LINK error (DEV_CONNECT_ERR)Strange thing is this only happens when I have a direct cable connection between the USB-C port on the Mac and the ST-LINK V3 USB on the board - it works as expected if I connect via a USB-C hub.VS Code is also not able to connect to the board to run a debug session without the hub, so I suspect this is an ST-LINK USB driver issue on the Mac.

Hello Community,I’m facing an issue while loading a firmware HEX file using STM32CubeProgrammer. The HEX file is not downloading successfully. Could you please suggest what might be wrong or provide guidance on how to resolve this?

On Kubuntu 24.04 when double clicking onSetupSTM32CubeProgrammer-2.19.0.linuxan empty window appears and then closes again. If I runSetupSTM32CubeProgrammer-2.19.0.linuxvia the terminal (as admin or as user), I get this error:Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException at sun.awt.X11FontManager.getFileNameFromPlatformName(X11FontManager.java:174) at sun.font.SunFontManager.initCompositeFonts(SunFontManager.java:3506) at sun.font.SunFontManager.access$800(SunFontManager.java:65) at sun.font.SunFontManager$2.run(SunFontManager.java:555) at java.security.AccessController.doPrivileged(Native Method) at sun.font.SunFontManager.<init>(SunFontManager.java:386) at sun.awt.FcFontManager.<init>(FcFontManager.java:35) at sun.awt.X11FontManager.<init>(X11FontManager.java:57) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62

It would be nice if the further versions could be running on case sensitive file system on macOS.Currently I need to use an USB key formatted APFS only. Then i can run the installer and install the programmer on this USB stick. As I most of the time only need the command line tools (*CLI) I copied the binaries and some folders with data on my case sensitive disk. They work fine. Only the GUI is not possible on the case-sensitive file system. 

I have an old Ubuntu 18.04 system which allows STM32CubeIDE to run, but the STM32_Programmer failed because libm.so and libc.so were wrong. I found glibc-2.30 and copied the libraries into the same directory as the STM32_Programmer lib. Now I just get a seg fault, even when trying to just get the version number:bin/STM32_Programmer_CLI --version Segmentation fault (core dumped)Is there any way to figure out what might be the problem?   

I have a STM32N6570-DK and i can't seem to program it any more.  I tried it in both the STM32 programmer gui and terminal application.  So i can connect to the device read and read the flash but i can't seem to write to it any more.  I can't even erase the flash.  I have another  Boot 0 = 0 (L)Boot 1 = 1 (H)     

Dear,When running the FSBL that includes HAL XSPI initialization logic on the Nucleo-N657X0-Q board (MB1940-N657X0Q-C02), the flash erase with the STM32CubeProgrammmer v2.22 sometimes fails. However, if I leave out the XSPI initialization logic for accessing the NOR flash, flash erase always succeeds. BOOT pin 1 is set to DEV and I am loading the FSBL firmware directly into RAM.Do you have any idea why XSPI Init causes the flash erase to fail ?BR,EdwinD