STM32CubeProgrammer CLI v2.19.0 — Cannot program second double-word of an OTP row (STM32U385)
Product/Tool: STM32CubeProgrammer CLI v2.19.0
Target 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 to
program the second double-word of the same row fails silently (word remains
0xFFFFFFFF) or is rejected by the flash controller, even though the row should
not 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 a
row independently (each in a single operation), provided neither has been
written previously. However in practice, programming the first double-word
appears to immediately lock the entire row, preventing the second double-word
from being written.
================================================================================
OTP ADDRESS LAYOUT
================================================================================
- OTP base: 0x0BFA0000
- Each row: 16 bytes = 2 double-words (DW0 at offset+0, DW1 at offset+8)
- Example: Row at offset 160 -> DW0 = 0x0BFA00A0, DW1 = 0x0BFA00A8
================================================================================
WHAT WE TRIED
================================================================================
All commands below use:
STM32_Programmer_CLI -c port=SWD mode=UR
--------------------------------------------------------------------------------
Attempt 1: Two separate -w32 commands (2 words each)
--------------------------------------------------------------------------------
# Program first double-word (offset 160) — SUCCEEDS
STM32_Programmer_CLI -c port=SWD mode=UR -w32 0x0BFA00A0 0x33323130 0x00003534
# Program second double-word (offset 168) — FAILS (stays 0xFFFFFFFF)
STM32_Programmer_CLI -c port=SWD mode=UR -w32 0x0BFA00A8 0xDEADBEEF 0xCAFEBABE
Readback after both commands shows DW0 programmed correctly, DW1 remains
0xFFFFFFFF FFFFFFFF.
--------------------------------------------------------------------------------
Attempt 2: Single -w32 command with 4 words (16 bytes)
--------------------------------------------------------------------------------
# Write all 4 words in one command
STM32_Programmer_CLI -c port=SWD mode=UR \
-w32 0x0BFA00A0 0x33323130 0x00003534 0xDEADBEEF 0xCAFEBABE
Result: Only the first 2 words (DW0) are programmed. The second 2 words (DW1)
remain 0xFFFFFFFF.
--------------------------------------------------------------------------------
Attempt 3: Binary file write (-w with .bin file)
--------------------------------------------------------------------------------
Created a 16-byte binary file containing the desired data and wrote it:
STM32_Programmer_CLI -c port=SWD mode=UR -w 0x0BFA00A0 otp_data.bin
Result: Same — only the first 8 bytes are written.
--------------------------------------------------------------------------------
Attempt 4: Chained commands in one invocation
--------------------------------------------------------------------------------
STM32_Programmer_CLI -c port=SWD mode=UR \
-w32 0x0BFA00A0 0x33323130 0x00003534 \
-w32 0x0BFA00A8 0xDEADBEEF 0xCAFEBABE
Result: First double-word succeeds, second double-word fails.
--------------------------------------------------------------------------------
Attempt 5: Different row to rule out damaged OTP
--------------------------------------------------------------------------------
Moved to offset 176 (a fresh row) and successfully programmed DW0. Confirmed
the previous row (160) failure is repeatable on multiple fresh rows — only DW0
can be written.
================================================================================
VERIFICATION
================================================================================
Reading via:
STM32_Programmer_CLI -c port=SWD mode=UR -r32 0x0BFA00A0 4
Consistently shows the first 2 words written correctly and the last 2 words
as 0xFFFFFFFF.
================================================================================
QUESTIONS
================================================================================
1. Is this a known limitation of the STM32U3 OTP or the flash controller
when TZEN=0?
2. Is there a required sequence (e.g., specific register unlocking, delay
between double-words, or a different programming mode) to write the second
double-word of an OTP row?
3. Does STM32CubeProgrammer internally lock the row after programming the
first double-word? If so, is there a CLI flag or workaround to defer row
locking?
4. Is this addressed in a newer version of STM32CubeProgrammer?
================================================================================
ENVIRONMENT
================================================================================
- STM32CubeProgrammer: v2.19.0 (Linux x86_64)
- Board: NUCLEO-U385RG-Q
- MCU: STM32U385RGT6
- TZEN: 0
- Connection: SWD via ST-LINK, mode=UR