STM32CubeProgrammer (MCUs)

How to use EDATA as extended flash in STM32-C562RE?I disabled the EDATA_ENVerified CubeProgrammer can read 0x08400000Created a project from MX2Added EDATA_CODE (rx) in stm32c562xe_flash.ld in memory block as EDATA_CODE (rx)  : org = 0x08400000, len = 0x10000Added the following section:           .edata_code :            {                    . = ALIGN(16);                    KEEP(*(.edata_code))                   KEEP(*(.edata_code.*))                    . = ALIGN(16);            } > EDATA_CODEAdded the simple EDATA_Add() function in main:__attribute__((section(".edata_code")))            __attribute__((noinline))            uint32_t EDATA_Add(uint32_t a, uint32_t b)            {                    return a + b;            }Called it once from main()Build it and build was successfullBefore flashing, check the .map lines containing .edata_code and EDATA_Add and foundsomething similar to:            .edata_code    0x08400000 ...                                 0x08400000 EDATA_AddNow,

Setup: STM32H757 (device ID 0x450, rev V), ST-LINK/V2 firmware V2J48S7 over SWD, STM32CubeProgrammer v2.23.0 CLI on Windows 11.Problem 1: the CM4 boot address can't be set.STM32_Programmer_CLI -c port=SWD mode=UR -ob BOOT_CM4_ADD0=0x080E BOOT_CM4_ADD1=0x080Eprints "Warning: Option Byte: boot_cm4_add0, does not exist" (and the same for add1), and exits with code 0, so scripts don't notice. "-ob displ" shows only the single-core BOOT_ADD0/BOOT_ADD1, with no BCM4/BCM7. The silicon is dual-core: FLASH_BOOT4_CUR (0x52002048) reads correctly, and BCM4/BCM7 are set in FLASH_OPTSR_CUR.Cause, as far as I can tell: in Data_Base/STM32_Prog_DB_0x450.xml the H757 matches configuration 0 ("Security extension available && multi-core"). In v2.23.0, every dual-core field leaves out config 0, while the single-core BOOT_ADD0/1 does include it:BCM4 (FOPTSR_CUR): config "1"BCM7 (FOPTSR_CUR): config "1,4,5"BCM4, BCM7 (FOPTSR_PRG): config "1,4,5"BOOT_CM4_ADD0/1 (FBOOT4_CUR and _PRG): config "1,4,5"BO

Wiring from st link to the stm32g061Error message It does not connect to STM32CubeProgrammer with the stm32G061 it keeps saying Error: unable to get core IDError: No STM32 target found! If your product embeds Debug Authentication, please perform a discovery using Debug Authentication. I have NRST pulled high with a 10k ohm resistor and then a tactile button which will make it go low when pressed.  The pinout for the STM32G061 is the same as the STM32G050 and when I have the same wiring as I did with the STM32G050 on this st link v2, but with the stm32G050 it connected correctly in STM32CubeProgrammer.  Why doesn’t it work with the STM32G061?

I’m using CubeProgrammer v2.23.0 with the SDMMC_STM32N6570-DK external loader (no additional loaders). I have the boot switches in the boot0=L, boot1=H positions. I have looked at all the posts similar to this one, however none of the suggested fixes have helped.When I try to program the eval board I get the following error message ... NOTE: I am able to download a new GUI directly from TouchGFX to external flash and it is fine. So, this is obviously an issue with CubeProgrammer/settings within? 

Hello Community :) We are using STM32N657 series MCU and flash MPN : S25FS512SDSBHV213, The flash supports two erase mode Hybrid (default) and Uniform erase. When we flash/overwrite a new binary it does not work properly, even the Full chip erase is enabled What we have to do for image to be working we have to go to erase external memory section and have to perform full chip erase and it takes roughly 5 mins to erase,​​​​​Without this it is not working, what we want, is there any option in the cubeprogrammer to erase the flash while/before programming ? other than this

PROBLEM:When loading a program, with size filling an odd number of memory sectors, into flash memory the program only starts every other upload. I have a custom board with an STM32L4KBU. I am connecting to the stm32 with the STLINK-V3SET, over SWO. I am developing with the VSCode STM32CubeIDE extension pack, on linux mint.STM32CubeProgrammer version: 2.23.0Boot0 pin is pulled to GND through 10k, default boot option bytes When using the STM32_Programmer_CLI to upload code there is a bug where the FLASH_SR PEMPTY register is not cleared correctly. It appears that the flash loader resets the register by writing all 1s, but the PEMPTY bit is specifically write 1 to toggle. This actually seems to be an odd design choice as the rest of the bits are write 1 to clear, and the language in the RM0394 Reference Manual is quite inconsistent (section 3.7.5, bit 17). A correct reset is to set this register to itself.The FLASH_SR register seems to get this toggling for every sector written into flash

I have been trying to download the STM32CubeProgrammer for several hours without success.  It looks like this is a common problem.  Could you please look into this?

For STM32C562RE, why can CubeProgrammer validate the OEM key and report "RDP2 unlocked successfully", while the RDP regression does not erase the existing user flash and flash erase remains prohibited? Is this a known CubeProgrammer/ST-LINK limitation or does this indicate that the device was provisioned with a non-regressible security configuration?Device: STM32C562RETx / NUCLEO-C562RECubeProgrammer: v2.22.0ST-LINK: V3J17M11SWD connection works.Device ID: 0x44E.OEM key is available.RDP unlock operation sometimes reports:"Validation Status: 3"followed by:"RDP2 unlocked successfully"After physical power removal and restoration:RDP_level = 0xFF (Unknown Value)Flash still contains:0x08000000 : 200007C8 08000671 0800073D 08000735Mass erase:Error: Mass erase operation failed. Please verify flash protectionProgramming:Erasing internal memory sector 0Error: failed to erase memory

Hello ST Community,I am working with the STM32H7RS-DK (STM32H7S78-DK) board and trying to program/activate the Open Bootloader using STM32CubeProgrammer.The Open Bootloader .bin file downloads successfully to RAM, but the Init Open Bootloader operation fails with an acknowledgement timeout.Provisionning logs========== Provisioning of OEMiROT boot path===== Application selected through env.bat: ..\..\..\Applications\ROT\OEMiROT_Appli===== Product state must be Open. Execute  \ROT_Provisioning\DA\regression.bat if not the case.===== DTCM/ITCM_AXI_SHARE is going to be forced to 0 for the provisioning steps===== (if needed uncomment DTCM/ITCM_AXI_SHARE lines with the wished value in the ob_flash_programming script).=====Step 0: Preliminary stage   * Define product state value (* default choice)OPEN       [ OPEN | CLOSED* | LOCKED ]: CLOSED   * Define Debug Authentication method (* default choice)       [ CERTIFICATE* | PASSWORD ]: PASSWORDStep 1: Configuration management   * OEMiROT_Config

Hello ST Community,I’m developing a custom external loader for a GD25Q64E flash device and cannot get STM32CubeProgrammer to read/write/erase the external flash. I’ve attached a screenshot of the error reported by the programmer.What I’ve doneFollowed the ST tutorial “External QSPI loader how to” External QSPI loader how to - STMicroelectronics. Verified read/write/erase work when exercised from main.c — no errors there. When running the loader, I see a hardfault reported in the CubeProgrammer “HardFault” tab. There is a hardfault at the end of loader_src.c in init(); I’m not sure whether that is expected. Project uses SPI3 with DMA and interrupts to talk to the external flash. I have also tested this with just polling and verified read/writing/erase work when exercised from main.c Device and external flash infoFlash: GD25Q64E SPI instance: SPI3 (Polling)Questions:  Any troubleshooting tips for getting the custom loader working with STM32CubeProgrammer (and diagnosing the hardfault sho

EnvironmentSTM32CubeProgrammer: 2.23.0 (latest version at the time of writing) The same issue was also present in the previous release and is still reproducible after updating to 2.23.0, which is why I am reporting it now. Platform: macOS Tahoe 26.5.1 Architecture: Apple Silicon (M4 Pro, arm64) System proxy: Enabled Proxy software: Clash Verge Rev (running continuously in the background) TUN mode: Enabled The proxy itself works normally for all other applications.Issue DescriptionI noticed that simply leaving STM32CubeProgrammer running causes the file ~/.STM32CubeProgrammer/Updater_Gui_Log.txt to grow continuously at a very high rate. The file increases by hundreds of megabytes within minutes and can easily reach multiple gigabytes if STM32CubeProgrammer is left open. In my case, I have already experienced the log file completely filling my macOS system disk overnight, which caused abnormal system behavior due to the disk running out of free space.Log OutputThe updater repeatedly writ

I’ve installed the newes STM32CubeProgrammer version on my Apple Silicon Mac. Now when I am running, it directly crashes. Digging a bit deeper via command-line gives: oading PRG Library: /Applications/STMicroelectronics/STM32Cube/STM32CubeProgrammer/STM32CubeProgrammer.app/Contents/Resources/bin/libCubeProgrammer_API.dylib108 external Loader listException in Application start methodjava.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:382) at com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:321) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method

Hello,I am investigating a Flash programming issue on an STM32H7A/B device with 1 MB Flash (Device ID 0x480, Rev X). STM32CubeProgrammer v2.21.0 treats the internal Flash as a continuous range 0x08000000–0x080FFFFF.Adresses such as 0x08080000, 0x080C0000 and 0x080FFE00 are programmed successfully and code placed there executes correctly, even though these addresses appear to be outside the documented Bank1/Bank2 address ranges in RM0455 Table 15.However, the HAL/CMSIS headers define FLASH_BANK2_BASE as 0x08100000, so IS_FLASH_PROGRAM_ADDRESS_BANK1(0x08080000) returns true and HAL_FLASH_Program() uses CR1/SR1 for that address. Programming 0x08080000 this way results in ECC problems when the location is read back. Could you please clarify the correct Bank1/Bank2 mapping for the 1 MB STM32H7A/B devices, whether 0x08080000 should be programmed through CR1/SR1 or CR2/SR2, and whether this is a known HAL/CMSIS issue?This is currently blocking our bootloader/FUOTA implementation, so a quick c

The oemirot provisioning tool expects the TrustedPackageCreator_CLI inside the same folder under mac osx silicone of the STM32CubeProgrammer. This yields an error for the provisioning.py script of these examples. So the python scripts won’t work anymore. I guess the development teams did not synchronise this fact.

Hello, I’m having some issues connecting my sensor tile box pro to my pc via a USB cable and with an ST-Link V2. I’ve followed the documentation regarding DFU mode, and the board doesn’t respond to it in STM32 Programmer ( I’ve double checked  if its a data cable, and this was confirmed). With the ST-Link, my Device Manager recognizes the debugger, but it has issues communicating/connecting with the board. However, I am able to flash it via Bluetooth. Is there some initialization I missed?

As shown in the picture above, on Fedora 43, the CubeProgrammer application is not matching the OS scaling and there are no options to configure it like in CubeMX. CubeProgrammer is the latest version (v2.22.0), installed today.My computer is a laptop with a 2256x1504 screen and OS-level scaling is set to 133%. All other applications behave as expected, I only ever have issues with ST’s applications.This issue has been reported multiple times in the past on different linux distributions. I have tried all suggested fixes in those posts, none worked. Links to other issues that had no solutions: 

ProblemSTM32_Programmer_CLI.exe -c port=SWD sn=<sn> and -l stlink-only each take ~30 seconds (sometimes much more) under v2.23.0 when launched programmatically by another application (CreateProcess, stdio redirected to pipes, no console window) — the pattern any automated test/programming tool uses. CPU stays near-idle during the delay.Expected behaviorSame as v2.22.0 and same as running the CLI interactively on v2.23.0: under two seconds. Reinstalling v2.22.0, with no other change to our application, fixes it immediately.What doesn't explain itRuled out through direct testing: console presence, output redirection style, handle inheritance, antivirus, elevation, 32/64-bit calling process, working directory, concurrent vs. sequential calls, a full reboot, network reachability (disabled proxy auto-detect, firewall-blocked the exe, disabled WiFi entirely — none changed the timing), and the local Analytics\TrackedData.json cache (already empty).A Process Monitor trace of a slow call

I downloaded and installed stm cube programmer, but every time I try to open it, I immediately get an error message saying that it quit unexpectedly. Currently running mac high sierra 10.13.6. How can I fix this problem?

EnvironmentMCU: STM32H573 (custom board) STM32CubeProgrammer & STM32 Trusted Package Creator: v2.23.0 (same version) X-CUBE-RSSe: installed (RSSe SFI binary v3.1.0, RSS v2.2.0) License: ST HSM (hsm=1, slot=1) Boot: custom OEM bootloader (OEM-iRoT), not STiRoT / not mcuboot Connection: HotplugWhat I'm doing I'm evaluating SFI without Secure Manager, installing my own firmware into internal secure flash. TrustZone is enabled (TZEN=0xB4), and my final option bytes (CSV) set:BOOT_UBE = 0xB4 (OEM-iRoT) SECBOOTADD = 0xC0000 (0x0C000000) SECWM1 = 0x00–0x7F, SECWM2 = 0x00–0x7F (all secure)Memory layout (secure alias 0x0C000000):File Address Size 1.bin 0x0C000000 22.2 KB 2.bin  0x0C008000 ~813 KB total 3.bin 0x0C0F7FA0 80 B 4.bin 0x0C0F8000 32 B 5.bin 0x0C1F8000 5.6 KB Behavior The SFI process starts correctly:License processed OK Image header processed OK Area 1 (type H) processed OK Fails at Area 2 with:Error: Execution of RSS CMD failed, returned value = 0xF

  Referred Ticket: How to run program on STM32N6 after flashing without changing BOOT-1 jumper | CommunityThank you for confirming that it is possible to run the application while keeping BOOT1 in DEV_BOOT mode by loading a RAM executable, performing a core reset, setting the SP and PC, and then running the core.My target is: STM32N6570-DKI need to achieve the following flow: Flash and verify the complete HEX file (Example: STM32N6-GettingStarted-ImageClassification/Binary/STM32N6570-DK at main · STMicroelectronics/STM32N6-GettingStarted-ImageClassification) Keep the STM32N6570-DK physically in DEV_BOOT mode. Start the flashed application automatically without manually changing the BOOT1 jumper. Perform the complete operation through command-line tools or a user script. The following command successfully flashes and verifies the image:STM32_Programmer_CLI.exe `-c port=SWD mode=UR reset=HWrst `-el "ExternalLoader\MX66UW1G45G_STM32N6570-DK.stldr" `-w "STM32N6570-DK_GettingStarted_I

Hi,by chance I found the “RoT Provisioning Software Pack” (https://github.com/STMicroelectronics/stm32-util-rot-provisioning).Looks promising; are there already any examples using it? I’m currently in the process of adapting the H563ZI OEMiROT examples in some custom project. Kolja 

 STM32_Programmer CLI, reconnect fail after change option byte by usb. | Community Has this been resolved?

Dear STM Support Team,the following CLI command takes about 30 seconds on a Raspberry Pi (thanks again btw!) compared to 1 second max on windows: STM32_Programmer_CLI -c port=swd sn=xyz I am using this in a loop to detect whether a MCU is connected.All other commands i tried are comparable in speed to windows so i guess this is a bug.The Pi is a Model 5 running Bookworm and a 6.12 kernel. Thank you very much!