Why must you set flash wait states before increasing the core clock?

Flash memory is slower than a fast CPU core. At low clock speeds the core can fetch an instruction from flash in a single cycle, but as you raise the clock, the flash access time eventually exceeds one core cycle, so the core must insert wait states, extra cycles where it pauses for the flash to deliver valid data. The wait-state count is a configurable setting that must match the core frequency per the datasheet's frequency-vs-latency table. The ordering is critical: if you raise the core clock before increasing the flash wait states, the core starts fetching instructions faster than the flash can supply them, reads invalid/partial data, and almost always HardFaults or hangs immediately, a bricked-looking chip. So the sequence is: increase flash latency first, then switch to the higher clock. When lowering the clock you do the reverse, drop the clock first, then reduce wait states. This is one of the most common bugs in hand-written clock-init code.