STM32 Production Bricking! 30% Programming Failure Rate? Using STM32CubeProgrammer Scripts + CRC Check, Yield Soars to 99.9%!

A batch of 1000 units in production, the programming site exploded

This incident occurred at the end of last year when we were working on an STM32G0B1 smart control board, preparing to deliver 1000 sets to a customer.

All hardware verification was completed, and functional testing passed. The last step was programming—we burned the firmware into the MCU, then labeled, packaged, and shipped.

The programming method used was via the SWD interface, combined with STM32CubeProgrammer and a production programming fixture. Initially, we operated manually, with engineers clicking “Start Programming” to program each unit.

However, as the volume increased, we switched to “batch programming,” and problems arose:

  • 20-30 units out of every 100 could not start after programming
  • Some would freeze after running for a while
  • Some empty units were not programmed at all but reported no errors
  • Some programmed the wrong address, directly overwriting the Option Bytes

Initially, we thought it was a hardware issue, so we replaced the Flash, changed the power supply, and checked for power interference—all were inspected,but we ultimately found that the programming process itself was unstable.

We manually sorted through that batch for two days, reprogramming and returning units, which left the customer very dissatisfied.

Later, I spent a weekend restructuring the entire production programming process:

  • Switched to STM32CubeProgrammer CLI (command line) automation scripts
  • Added an empty chip detection mechanism to avoid programming the wrong chips
  • Performed CRC checks after programming (hardware or software)
  • Added a locking mechanism for writing Option Bytes

Subsequently, all 20,000+ STM32 units were successfully programmed, maintaining a yield of over 99.9%.

1. Why is manual programming prone to errors?

Our initial process was quite simple:

  1. Open STM32CubeProgrammer GUI
  2. Connect the device → Click “Connect”
  3. Load <span>.hex</span> file
  4. Click Program → Wait for programming to complete
  5. Click Verify

This process worked well during the development phase, but once we entered production:

  • Operators often forgot to click “Verify”
  • Sometimes connections failed without reporting an error
  • Programming failures still prompted “Success”
  • Multiple chips powered simultaneously could lead to programming the wrong target

As a result, we ended up with a bunch of chips that were partially programmed, or those that failed halfway through but were still shipped.

2. Switching to command line scripts + empty chip detection + CRC checks

I later took over the entire process with command line scripts, triggered by a fixture button, programming one chip at a time, automatically verifying after programming, and alerting on failure.

✅ Using STM32CubeProgrammer CLI

The CLI tool is named <span>STM32_Programmer_CLI.exe</span>, and it supports:

  • Connecting to devices
  • Programming Flash
  • Programming Option Bytes
  • Verifying Flash memory
  • Reading chip UID
  • Checking empty chip status

Example script (Windows batch file):

bat

@echo off
set HEXFILE=firmware.hex
set PORT=SWD

echo [1] Checking for empty chips ...
STM32_Programmer_CLI.exe -c port=%PORT% mode=UR reset=HWrst -ob displ -el

if errorlevel 1 (
    echo Empty chip check failed, skipping programming
    exit /b 1
)

echo [2] Programming firmware ...
STM32_Programmer_CLI.exe -c port=%PORT% mode=UR reset=HWrst ^
                         -w %HEXFILE% -v -rst

if errorlevel 1 (
    echo Programming failed!
    exit /b 1
)

echo [3] Verifying CRC ...
STM32_Programmer_CLI.exe -c port=%PORT% mode=UR ^
                         -crc addr=0x08000000 size=0x10000

if errorlevel 1 (
    echo CRC verification failed!
    exit /b 1
)

echo Programming successful, preparing for the next chip
pause

3. Empty chip detection mechanism

When STM32 chips leave the factory for the first time, the Flash is all <span>0xFF</span>, and you can use <span>-el</span> (empty check) to determine:

bash

STM32_Programmer_CLI.exe -c port=SWD -el

The returned content includes:

Memory isempty

We added this step before programming to avoid programming already programmed chips, preventing repeated erasure or incorrect programming.

4. CRC Check: Not verifying after programming = running naked

Method 1: Built-in CRC check of CLI

bash

STM32_Programmer_CLI.exe -c port=SWD -crc addr=0x08000000 size=0x10000
  • You need to know the firmware size (for example, 64KB = 0x10000)
  • It will return a CRC value, which you can compare with the CRC at compile time (found in the .map file)

Method 2: Write a fixed CRC value into the firmware → Bootloader verification

Later, we added the following to the project:

  • The last 4 bytes of the firmware store CRC32
  • The Bootloader automatically calculates the entire App area CRC at startup
  • It only jumps if matched; otherwise, it enters an error state

This way, even if the programming tool does not verify, the device can still protect itself.

5. Pitfalls of Option Bytes: A careless mistake can lead to incorrect programming

After programming a batch of chips, we found that the Option Bytes had been altered:

  • Some chips had BOOT0 = 1 by default, directly skipping the Bootloader
  • Some chips had RDP changed to 1, making debugging impossible

I later added a script command to force write the correct Option Bytes:

bash

STM32_Programmer_CLI.exe -c port=SWD -ob RDP=AA nWRP=0x00 BOOT_SEL=0 BOOT0=0

Then lock it:

bash

STM32_Programmer_CLI.exe -c port=SWD -lock

Option Bytes must be written clearly; do not use your development configuration as the default for production chips.

6. How to establish a complete production programming process

We now use a combination of a foot switch + production fixture + industrial computer + STM32 CLI scripts:

  1. The operator inserts the chip + foot switch
  2. The industrial computer automatically runs the CLI script:
  • Check connection
  • Detect empty chips
  • Program firmware
  • Verify CRC
  • Write Option Bytes
  • Authenticate UID (optional)
  • Programming successful → Buzzer sounds
  • Programming failed → Red light on + log recorded

    • We record UID, time, and verification status for each programming session for traceability.

    7. Results: Yield skyrocketed, customer satisfaction, and peace of mind for us

    After implementing this script + verification process:

    • Subsequent programming of over 20,000 STM32 chips was successful
    • Failure rate dropped from 30% to <0.1% (due to human contact issues or chip damage)
    • The customer randomly checked 100 units during acceptance, and all passed

    We have not received any more complaints about “not working after programming,” and no longer need engineers to supervise programming on-site.

    Leave a Comment