STM32G474 Fast Flash Programming: Verify the Row Size and Erase Scope Before Writing

Ordinary doubleword programming working on an STM32G474 does not establish that fast programming is eligible for the same region. Fast mode has a broader erase prerequisite and a tightly coupled feed sequence. A page that looks erased is not, by itself, the complete admission condition.

The scope is category 3 STM32G474 in RM0440 Rev 9, March 2025, Table 1 and section 3.3.7. This is a non-mutating feasibility review. No mass erase, flash write, option-byte change, programmer session or target test was executed, and no executable erase recipe is supplied.

Select the category before counting the feed

Table 1 places G474 in category 3. Section 3.3.7 describes 64 successive doublewords, giving a 64 * 8 = 512 byte feed. However, the same category’s MISSERR definition on page 133 says 32. This unresolved source discrepancy makes 64 the functional-section model used here, not an execution-ready hardware guarantee.

Section 3.3.7 calls the transfer a row with DBANK = 1 and a half-row with DBANK = 0, retaining 64 doublewords in both cases. Record the bank mode and source section; neither the category 4 chapter nor the word “row” resolves the category 3 inconsistency.

Also retain the access contract. The manual describes each aligned doubleword through two word writes and requires successive addresses within the applicable row constraints. A 512-byte application buffer does not prove that the implementation emits the required sequence or observes its alignment rules.

Treat erase scope as a design decision

For single-bank mode, the documented prerequisite is a mass erase. For dual-bank mode, it is a mass erase of the bank being programmed. The manual associates a missing prerequisite with PGSERR. Erasing only the destination page does not satisfy the stated fast-mode condition.

This is a reason to stop and review feasibility, not permission to erase more memory. The affected bank can include a bootloader, calibration, device identity or other valuable contents outside the proposed 512-byte payload. Preserve those ownership requirements before selecting a programming mode.

If the product cannot accept the necessary erase scope, evaluate another supported programming design, including ordinary programming under its own rules. Do not modify bank-mode option bytes merely to make this example convenient. Erase eligibility and programming speed are different engineering decisions.

Account for both feed gaps and read interference

Fast programming requires HCLK of at least 8 MHz in this chapter. That threshold is a prerequisite, not a complete worst-case execution-time proof. Interrupts, source-buffer access, helper calls and competing work can still interrupt the sequence of doubleword requests.

The manual explains that an excessive gap between requests interrupts fast programming and sets MISSERR. Its approximate programming-time example must not be promoted to a universal electrical maximum or used as the sole scheduling margin. An implementation needs the applicable device conditions and a bounded feed path.

A separate warning concerns an overlapping read from the same bank: the fast-programming attempt can abort without an error flag. Consequently, “no error bit observed” cannot establish that the intended data was programmed. Code placement alone is insufficient if vectors, constants, helpers or another access path still read the affected bank.

For single-bank mode, the described fast path requires execution from RAM or the bootloader. In any chosen arrangement, inspect the final linked code and data dependencies. Do not assume a source annotation moved every called function and literal, or that a warm instruction cache proves there will be no flash read.

Preserve the partially programmed outcome

The manual states that, when an error stops the sequence, earlier doublewords have already been programmed while the next one is not programmed. Failure therefore does not imply an untouched destination or automatic rollback of the prefix.

A hypothetical interruption after several accepted doublewords leaves a mixed outcome to reconcile. Do not immediately retry the whole payload as though it were the first attempt, and do not mark the complete row valid because an early prefix compares correctly. Recovery must follow the exact flash rules and the product’s approved data-preservation policy.

Keep completion status, errors and subsequent content verification as separate evidence. Verification itself must occur through a supported post-operation path; this article does not propose reads during the prohibited overlap or invent a guarantee from the cleared busy indication alone.

Finish with an eligibility worksheet

Before implementation, record category, bank mode, intended address range, required erase scope, all data sharing that scope, feed count, access width and alignment, minimum clock condition, code/source/vector placement and failure recovery. Any unresolved row is a reason to withhold an execution-ready procedure.

The category 3 MISSERR register description’s 32-doubleword count conflicts with section 3.3.7’s 64-doubleword sequence. Execution-ready code requires reconciliation through a pinned implementation or vendor guidance. Apparent caption and register-name slips also need checking; this article deliberately stops at feasibility and failure boundaries.

A later qualification requires a separately approved sacrificial fixture and complete recovery plan. The immediate result is a decision about whether fast mode fits the product at all, together with an explanation of how a feed interruption or hidden same-bank read can defeat an otherwise plausible programming attempt.