Why Does STM32U535 TrustZone Non-Secure Flash Fail?

Non-secure programming at 0x08020000 succeeds and verifies after changing the STM32U535 flash organization from dual-bank to single-bank with DBANK=0. Correcting the secure watermark remains necessary: the secure region must stop before the non-secure image address. Treat the download-complete message as a transport result only; the readback comparison is the acceptance test.

Failure Signature and Acceptance Criteria

The failing setup used STM32CubeProgrammer v2.22.0, ST-LINK firmware V2J47S7, SWD Hot Plug mode at 4000 KHz, and a target voltage of 3.28 V. The detected device was an STM32U535/STM32U545, device ID 0x455, revision Y, with 256 KBytes of nonvolatile memory.

The command downloaded a 16-byte binary to the non-secure image address:

STM32_Programmer_CLI.exe -c port=SWD mode=HotPlug -d test16.bin 0x08020000 -v

Erase and download both reported completion, but verification read 0x00 where the file contained 0xEF at 0x08020000. That distinction narrows the problem: the host transferred the data, but the final flash contents at the requested address did not match.

Check 1: repeat the 16-byte test with -v. Expect no mismatch at 0x08020000 before treating the flash path as commissioned.

Address Map and Security Boundary

The term secure watermark here means the option-byte range that attributes flash pages to the secure domain. With TZEN=1, an address intended for the non-secure image must fall outside every active secure watermark.

The original configuration placed SECWM1_PSTRT=0x0 at and SECWM1_PEND=0x1F at . For the reported 256-Kbyte device, those displayed endpoints span the flash address space represented by the programmer. The intended non-secure boot address, NSBOOTADD0=0x100400, decoded by the tool as 0x08020000, therefore lay inside that original secure range.

The corrected boundary used SECWM1_PEND=0x0F, displayed as . The next displayed boundary is 0x08020000, so the corrected configuration creates the intended division: secure flash below the non-secure start and non-secure flash beginning at 0x08020000. This is the reported 128-Kbyte/128-Kbyte split.

Bank 2 showed SECWM2_PSTRT=0x1F at and SECWM2_PEND=0x0 at 0x08020000. Because the displayed start is above the end, this range does not describe an ascending secure interval. Confirm the programmer continues to display those exact values after every option-byte operation.

Check 2: display the option bytes and expect NSBOOTADD0 to resolve to 0x08020000, while SECWM1_PEND resolves to . If the secure end again displays , correct the watermark before programming.

Option-Byte Baseline

Capture the active configuration before changing it:

STM32_Programmer_CLI.exe -c port=SWD -ob displ

Use the decoded output rather than relying only on a successful option-byte write message. The relevant baseline values were:

Changing several protection states at once obscures causality. The attempted recovery moved RDP to 0xBB, then returned it to 0xAA while clearing TZEN. It did not resolve the programming failure after TrustZone and the watermarks were restored. Use that sequence only as a controlled recovery operation, not as the primary correction for this symptom.

Check 3: after reconnecting, run -ob displ again. Expect RDP=0xAA, SWAP_BANK=0x0, and the planned TrustZone state. Stop if the decoded values differ from the values just written.

Write-Protection Exclusion

Write protection must be excluded before changing the bank layout. Both protection ranges were reported unlocked. For Bank 1, WRP1A_PSTRT and WRP1B_PSTRT were 0xF, while both corresponding end values were 0x0; UNLOCK_1A and UNLOCK_1B were 0x1. Bank 2 reported the same start/end pattern through WRP2A_* and WRP2B_*, with both unlock fields at 0x1.

That output separates write protection from security attribution. A non-secure address can be outside an enabled write-protection range yet still be inaccessible because a secure watermark or bank mapping assigns it differently. Clearing write protection repeatedly will not correct an address-attribution fault.

1. Display all option bytes with -ob displ.
2. Inspect both A and B protection ranges for each displayed bank.
3. Confirm the output explicitly describes each range as unlocked.
4. Check HDP1EN=0x0 and HDP2EN=0x0 so a hidden-protection region is not part of the diagnosis.

Check 4: expect all four reported write-protection areas to remain unlocked and both HDP enable fields to remain zero. If not, correct that protection independently before testing DBANK.

Secure-Watermark Programming

Commission the watermark before loading either image. The attempted combined operation exposed an ordering constraint in the programming workflow: the watermark option names were unavailable while TrustZone was disabled. Enabling TZEN recreated the prior incorrect SECWM1_PEND=0x1F, so the watermark then had to be corrected explicitly.

1. At RDP=0xAA, establish a known erased baseline and confirm that the small binary can be addressed when TrustZone is disabled.
2. Enable TrustZone using the connection mode that remains reliable for the target. The tested command form was STM32_Programmer_CLI.exe -c port=SWD mode=HOTPLUG -ob TZEN=1.
3. Reconnect and display the option bytes. TrustZone activation may expose the secure-watermark field names to the programmer.
4. Set SECWM1_PSTRT=0x0 and SECWM1_PEND=0x0F.
5. Set SECWM2_PSTRT=0x1F and SECWM2_PEND=0x0.
6. Reconnect again and read the decoded addresses, not merely the hexadecimal field values.

mode=UR was used during some attempted option-byte writes, while mode=HOTPLUG was used successfully for other TrustZone operations. Connection mode is secondary here: accept a mode only when the subsequent option-byte display reports the intended persistent values.

Check 5: expect , , , and SECWM2_PEND=0x0 (0x08020000).

Single-Bank Flash Selection

Correcting SECWM1_PEND removed the obvious overlap but did not make the non-secure image programmable. The decisive change was DBANK=0. With DBANK=1, the device reported dual-bank flash with contiguous addresses; the erase log identified internal sector 16 for 0x08020000. Bank organization affects how the flash controller and programming algorithm translate logical addresses into physical erase/program units. Security boundaries must agree with that organization.

Set the option byte through the same STM32CubeProgrammer option-byte interface used for the other fields. Using the demonstrated CLI form, the operation is:

STM32_Programmer_CLI.exe -c port=SWD mode=HotPlug -ob DBANK=0

An option-byte change can require the programming session to reconnect before the new memory organization is visible. Do not continue using cached option-byte output or a connection opened before the change.

1. Write DBANK=0.
2. Disconnect and reconnect the programmer.
3. Run STM32_Programmer_CLI.exe -c port=SWD -ob displ.
4. Confirm DBANK : 0x0 before erasing or downloading.
5. Recheck the secure-watermark decoded addresses because the bank-layout change and security configuration must describe the same intended boundary.

Check 6: expect the live option-byte display to report DBANK=0, with the secure region ending before 0x08020000.

End-to-End Programming Verification

Verify the configuration with the smallest failing artifact before loading the complete secure and non-secure applications. This keeps application startup, vector-table content, and inter-domain calls outside the flash-programming test.

1. Reconnect over SWD and record the detected device, supply voltage, and option-byte display.
2. Confirm RDP=0xAA, TZEN=0x1, SWAP_BANK=0x0, and DBANK=0.
3. Confirm the corrected watermark endpoints and all write-protection areas remain unlocked.
4. Program the 16-byte binary with STM32_Programmer_CLI.exe -c port=SWD mode=HotPlug -d test16.bin 0x08020000 -v.
5. Require verification to complete without Data mismatch found at address 0x08020000.
6. Program the non-secure application first, then the secure application.
7. Reset and run the target. Confirm execution transfers to the configured non-secure boot address and that a fresh programmer readback still matches the programmed image.

Check 7: expect the byte at 0x08020000 to equal the file value—0xEF in the recorded 16-byte test—not 0x00. This readback is the final proof that erase, programming, security attribution, and flash organization agree.

FAQ