STM32CubeProgrammer (MCUs)

I have a custom PCB with an blank, unflashed STM32L4R and my goal is to flash it with firmware via the ST-LINK on my NUCLEO board that hosts another STM32L4R. The only pins I connected for debugging/flashing purposes is USB_DM and USB_DP, the rest, like NRST, SDWIO, SWCLK, SWO, BOOT0 are left unconnected. I am able to jump those pins to my ST-LINK or my USB device, however, my current method of flashing is jumping NRST, SWDIO, SWCLK, and SWO to my ST-LINK and programming it using STM32CubeIDE and STM32CubeProgrammer. I disconnected the jumpers on the ST-LINK that connect it to the NUCLEO MCU, which in theory should allow my PCB STM32 to become the target, however, I am getting launch sequence errors within STM32CubeIDE as well as "Target Not Found" errors in STM32CubeProgrammer. I included screenshots below and I tried switching modes and such, but nothing is working. I have connected CN5 Pin 1 to 3.3V, CN5 Pin 2 to PA14 on my PCB MCU, CN5 Pin 3 to ground, CN5 Pin 4 to PA13 on my targe

I just bought discovery kit for STM32MP1 and I have connected power and JTAG USB.When I am clicking on connect, I am getting below error. Can you please tell how to connect? 

I created an external flash STLDR file for my board, with STM32H750VB chip and W25Q64 QSPI FLASH. After copying the STLDR file to the cubeprographer directory, it can perform normal external flash read/write and sector erase functions. However, when selecting full chip erase, the cubeprographer prompts me "please select external loader before performing external full chip erase". But I am sure that my code contains the correct int MassErase (void) function, and I used the readelf command in Ubuntu environment to read the STLDR file I created, which also includes the MassErase function. But it seems that this function cannot be correctly detected by the cubeprographer. How can I locate the cause and solve this problem?Wishing you peace

Hi teams,Board: Nucleo-U083RCCPU: STM32U083RToday, I faced a problem with my new board while performing RDP regression using the STM32 Cube programmer.The condition of the board prior to the issue,* Option bytes value: At default level.* Flash data: Default data [LED sample].Step that I followed,1.Initially, I have configured the OEM1 key values with a password, resulting in the transition of the OEM lock bit status from "not active" to "active". 2. I then configured only the RDP level in the Option bytes tab, changing it from Level 0[0xAA] to Level 1[0xBB], while the other OB values remained in their default state.3. I disconnected the programmer and subsequently reconnected it, allowing the changes to be reflected shortly thereafter.4. To perform the regression in the STM32Cube programmer, I adhered to the procedures outlined in UM2237 User Manual [section: 2.9.2 RDP regression with password].4.1. STM programmer connection settings4.2.  I have written the OEM

Hi,Many thanks for the experimental incremental flash feature! For me it speeds up the dev cycle considerably.  (Note https://wiki.st.com/stm32mcu/wiki/STM32CubeProgrammer_errata_2.21.x seems to be broken.)Dan 

Hello,I am trying to test the sbsfu project which is provided on this link. and I am using Unit Nucleo-F413ZH.I am following all the instructions step by step but on STM32Cubeprogrammer after opening file "SBSFU.elf", downloading it and then reading it by memory, I see these messages in the Log section:after it i try to compare the memory with the SBSFU.elf, and then I get these warnings: When I check the bytes, I don't see any difference but this warning appears, and I cannot see the welcome message on Tera Term.I tried all the process with other identical unit and everything goes right, but on this unit I encounter this issue.Also It's good to mention that I can run and execute any test projects via STM32CubeIDE. Thanks in advance. 

On my computer the `stldr` files are stored like `/opt/stm32cubeprog/bin/FlashLoader/0x469.stldr` and I'm sure they exists and have correct permission. Why would it try to open the file '0x' ? Is it just a bug of string concat? Currently I cannot flash the chips because of this bug.

I have a problem with installing STM32CubeProgrammer. The installion of this program has 9 steps. However, I cannot see step 8 and step 9. For this reason, I cannot install the program. When I am looking for the solution, some people say that computer's language should be converted to English but I have single language edition of Windows and the languge is not English. That's why I cannot converted it. Can you give another solution for this issue? As you can see, there is no such a thing, in step 8. For this reason, I cannot complete the installation. 

I am having some issues with getting UART uploading working. I can read the chip and get it's ID, but it keeps saying it cannot get acknowledgments.  Everything is directly connected. Serial TX/RX to their corresponding pins and RTS to Boot and DTR to Reset.At first, I thought it was because the FT232RNL chip has flipped polarity, but we can change this through the FTDI programmer. After changing it, I am still having the issue above. Looking online, I see some people put a cap in between the DTR and Reset. Is this actually required? I know they did not on Arduino's. but I always though it was because their bootloader required it since there was no boot pin like on the ST's.I cycled through all the possibilities for the DTR and RTS configuration in the ST Programmer software, but none of them seem to fix the issue.  Any guidance on this? 

Hello,On STM32U575VGT with MX25L6433F over OCTOSPI1, my external loader can read successfully only once. The next read operation hangs (5-second timeout). If I disconnect/reconnect the target, the first read succeeds again, then the second read fails the same way. HardwareMCU: STM32U575VGT (LQFP100)Flash: MX25L6433F (64 Mbit / 8 MB)Bus: OCTOSPI1, Quad 1-1-4MM base: 0x90000000 OSPI1 PinsPA6: IO3PB0: IO1PB10: CLKPE11: NCSPE12: IO0PE14: IO2 SymptomFirst read after connect: OK (e.g., 1024 B @ 0x90000000)Second read: FAIL (hang/timeout inside Read; CubeProgrammer reports “Init function fail with timeout” but my Init() actually succeeds — the hang occurs in Read() when touching MM region)MM access at 0x90000000 appears to stall on second attempt. Log ----- Read #118:22:50:670 : UPLOADING ...18:22:50:670 : Size : 1024 Bytes18:22:50:670 : Address : 0x9000000018:22:50:670 : Read progress:18:22:50:670 : Reading data...18:22:50:671 : halt ap 018:22:50:671 : w ap 0 reg 15

The "Discover" button on the STM32CubeProgrammer fails to connect to my my STM32H56x (STM32H562VGT6) in the Closed state (0x72). The instructions I followed for enabling password security are in the "How to enable RDP-like product state flash protection in STM32H5 microcontrollers" post. No errors came up in following these steps. To summarize my steps:1. Installed STM32CubeProgrammer and STM32TrustedPackage Creator2. Generated OBKey and password.bin files from DA_ConfigWithPassword.xml 3. Set PRODUCT_STATE to Provisioning (0x17) and executed "Start Provisioning" with the generated .obk file4. Set PRODUCT_STATE to Closed (0x72)  The issue arises when going to perform a regression. In the Debug Authentication window, clicking the "Discover" button does not prompt me to select a password file and throws an error that states "Failed to communicate with target !". The Debug Authentication sequence does not start. The same error occurs whether or not my ST-Link

We have a custom loader from one of our boards.  It is working in STM32 Cube MX Prog V2.16 but when I launch V2.19 and try to connect to a unrelated boards I get this error:The error is understandable because the path to the loaders is incorrect.  The issue is I never told V2.19 to use this external loader and it doesn't even show up in the list of available loaders.  It some how figured out that I have used this loader in the past (but it didn't quite figure out the correct location of the loader) and for some reason it is trying to access it.  I mess with loaders so infrequently I have no idea how to fix this issue.The custom loader does show up in V2.16 and doesn't produce this error: Suggestions? Jacob

Hello,I am using the discovery kit with STM32L562QE MCU (UM2617). I tried to disable the TrutZone following the instructions in this article : https://community.st.com/t5/stm32-mcus/how-to-disable-trustzone-on-stm32u5-series/ta-p/49793However, after doing Step 3 (in the article), I can no longer interact with my card. When I try to connect to it using STM32CubeProgrammer or by flashing, I always have the same error : ST-LINK error : DEV_TARGET_NOT_HALTEDI found some persons with the same problems :- https://community.st.com/t5/stm32-mcus-boards-and-hardware/st-link-error-dev-target-not-halted/td-p/278454- https://community.st.com/t5/stm32-mcus-boards-and-hardware/error-in-initializing-st-link-device-reason-9-target-not-halted/td-p/85174But the solutions described do not seem to work for me. Here is what I've tried :- Power off / Power on- Update STLink- Set NRST to high (because there are many NRST on the board, maybe I did not set the right ones)- Switching to

Hi,o.s.: Debian 12 Bookworm (fully updated)board: (official) STM32f4-discoverymicropython: STM32F4DISC-20250911-v1.26.1.dfuSTM32CubeProgrammer v2.19.0Checking my previous posts shows that I have tried this before but obviously got nowhere as I seem to have abandoned that attempt. So I am trying again...I'm trying to load Micropython onto the board listed above using ...Programmer but am having some problems doing so. I have connected both of the board's USB ports to the laptop.When I set ...Programmer connection mode to ST-LINK the board is connected and is erroneously(!) identified in ...Programmer's "Target Information" list as a device of type STM32F2xx. In this connection mode, the board has both ST-LINK jumpers in place and ...Programmer does display a "File download complete" message after downloading the .dfu file even though it is displaying "No DFU detected".When I set ...Programmer connection mode to USB, which I thought was necessary to flash/download a .dfu file t

When I am trying to use the STM32CubeProgrammer in Linux, only the default connection option of J-Link is available. No other options "drop down" in the drop-down menu. Since I am set up to connect over USB, this means I am unable to connect to or reprogram the board (STM32MP257F-DK). When I test this same thing on Windows, it shows USB as a connection option, and it can connect successfully. The drop-down menu appears normal. It used to work properly like this in Linux before, and I don't believe I changed any settings in STM32CubeProgrammer since then. Is there a way I can get the standard behavior back when using Linux? I am following the steps as described here: https://wiki.st.com/stm32mpu/wiki/Getting_started/STM32MP2_boards/STM32MP257x-DK/Let%27s_start/Populate_the_target_and_boot_the_image 

I'm not able to download STM32CUBE programmer from the site.

I have just received my STM32N6570-DK and tried to flash the external memoryWhatever I do :* program an Hex file* erase single sector* erase full memory I always have the same error : failed to erase memoryI have tried to revert cube programmer to version 2.19  but I still have the error.The bios of the board has been updated Any idea of what to do ?

Hi, I am trying to bring up some software on an STM32N6570-DK.I'm able to upload example code from the STM32CubeIDE when the board is in DEV mode, e.g. when BOOT1 is set to 1. I followed the steps in this KB article: FSBL Explained However, I am unable to even connect to the board with STM32CubeProgrammer, even when in DEV mode. Here are the logs from STM32CubeProgrammer: Port 010:59:00 : STM32CubeProgrammer API v2.13.0 | MacOS-64Bits10:59:21 : UR connection mode is defined with the HWrst reset mode10:59:21 : ST-LINK SN : 002000413234510E3733393410:59:21 : ST-LINK FW : V3J16M910:59:21 : Board : STM32N6570-DK10:59:21 : Voltage : 3.29V10:59:21 : Error: ST-LINK error (DEV_CONNECT_ERR)Port 110:59:25 : UR connection mode is defined with the HWrst reset mode10:59:25 : ST-LINK SN : 002000413234510E3733393410:59:25 : ST-LINK FW : V3J16M910:59:25 : Board : STM32N6570-DK10:59:25 : Voltage : 3.29V10:59:25 : Error: Cannot connect to access port 1! If you are trying to connect to a d

Split from Cannot connect to NUCLEO-N657X0-Q - which is solved.This is a new question.Follow up question: what should i do if i want to connect using flash boot?

Hello,(ST-LINK + CubeProgrammer UART/USB both failing)I am using a NUCLEO-N657X0-Q board. I cannot flashing my code via the ST-Link ( ST-Link windows driver is installed and detected through device manager and I had already updated the stlink). it throws this error:STMicroelectronics ST-LINK GDB server. Version 7.11.0Copyright (c) 2025, STMicroelectronics. All rights reserved. Starting server with the following options:Persistent Mode : DisabledLogging Level : 1Listen Port Number : 61234Status Refresh Delay : 15sVerbose Mode : DisabledSWD Debug : EnabledInitWhile : Enabled Target unknown error 32 Error in initializing ST-LINK device.Reason: Unknown. Please check power and cabling to target.Then tried with CubeProgrammer to connect via STlink but it connects then quickly drops , here is the log :17:22:24 : STM32CubeProgrammer API v2.20.0 | Windows-64Bits17:22:39 : UR connection mode is defined with the HWrst reset mode17:22:40 : UR connection mode is defined with the HWrs

Hi, I have been flashing STM32L151VE by using DFUSe tool for a while. But I could find some difficulty after the OS upgrade to windows 11. Also, I found that the DFUSe tool may not support new ST Boards as per official STM website, so I started using STM32Cubeprogrammer tool, with which I am unable to flash.When I select the erase option while flashing, it fails.When I skip the erase option while flashing, file download works, verification fails and it works inconsistently.Starting address for application part is 0x8008000.I tried integrating the DLLs and API provided in the installed tool's folder. By using methods: massErase() and sectorErase() as per the API, response is successful but when I manually check the memory, they are not erased and even the downloadfile() method fails.I tried doing the same with ST Link debugger interface and it works fine, but the issue still remains the same with USB DFU interface.So, can you please let me know on how to use these AP

Hi Community,I am trying to get the Automatic Mode working, without success. There is a very similar (but locked) post about this going back to 2021 here, for which there is no accepted solution, so this may be an unresolved bug.I am using API V2.20.0 and my ST-Link/V2 firmware is up to date. My target device is STM32C071 on my own pcb, using SWD. I have no issue with manual programming but automatic mode is problematic. To keep it simple until working properly, I am not programming any option bytes at this stage.I start with the ST-Link connected to a board, then click Start Automatic Mode. After a delay of a few seconds it is programmed no problem and the dialogue then requests the device be disconnected and does recognise that it has been. So far so good.However, it then fails to recognise the second device and hangs, not only the API but also the ST-Link, which must be unplugged and replugged before it will connect to a new instance of STM32CubeProgrammer.Is it something I'm d

I am using STM32G474RCT6 microcontroller, I want perform firmware upgrade through CAN communication. But my controller doesn't provide the feature of Firmware upgrade through CAN communication.is there any possibility to use CAN communication for firmware upgradation in my controller. 

  Hi, I created a project on the STM32N6570DK and I only have the project "in (STM32CubeIde)", I don't have the FSBL and the Appli. How do I flash my firmware? I tried to use the fsbl provided by the official ST repository, namely "ai_fsbl.hex", but the program does not start

Last week we ran into issues flashing our custom boards (STM32H7S3L8H6) with the STM32Progammer_CLI. Originally we were using the version packaged with CubeCLT 1.18.0 (STM32CubeProgrammer v2.19.0). I noticed that ~7% of flashes failed flash verification after a "successful" flash. The errors were always grouped within a small region of addresses, and this region stayed the same until a new .elf file was compiled. Using CubeProgrammer GUI i was able to validate that those memory regions were in-fact invalid. For example, here is one of the test runs on our custom board:=== Final Statistics === Total Flashes: 624 Successful: 580 Failed: 44 Success Rate: 92.95% Failed Addresses (failure count): 0x080065C8: 12 0x080065C9: 7 0x080065CE: 6 0x080065CF: 5 0x080065CD: 5 0x080065CA: 4 0x080065CC: 3 0x080065CB: 2 As you can see by the addresses, this was flashing the bootloader (in internal flash).The command used to flash for all versions wasSTM32_Programmer_CLI -vb