To unlock secured GD32F330F4P6 flash firmware is to work the smallest package GigaDevice gives this family: a 20-pin TSSOP body holding a Cortex-M4 at 84 MHz with zero-wait-state access, 16 KB of flash, 4 KB of SRAM, a 9-channel ADC and fifteen I/O lines. Small parts concentrate the unlock problem: there is little code to reconstruct, but there is also nowhere to hide a fixture, and the boards that carry TSSOP-20 devices are usually dense two-layer designs with no programming header to borrow.
Protection is governed by the SPC byte in the option byte area at 0x1FFFF800, with 0xA5 as the open value and any other value meaning protected; under protection, reads of the main flash from debug, SRAM boot or the system bootloader end in bus errors, while the option bytes themselves remain readable in every mode. That last fact does most of the diagnostic work: one read of 0x1FFFF800 tells you whether you are looking at a locked device or an empty one, before any pricing discussion. Restoring 0xA5 from a protected state makes the controller mass-erase the 16 KB array, so on a part this small the destructive route erases nearly everything there is to save — the argument for finding a surviving copy first is at its strongest here. The controller cracking overview and the unlock service arrangement set out how we stage that decision commercially.
Where a copy survives elsewhere, the project is a comparison dump; the locked sample stays untouched. Where it does not, the fixture work is the challenge: the SWD pair and reset must be reached on a package whose leads are separated by less than a millimetre, and the reset net on small boards usually needs one component lifted to present a clean edge to the programmer. Firmware on 16 KB parts is compact enough that a recovered image can be reviewed exhaustively — every page, every constant — and the analysis notes for small ATtiny images describe the same exhaustive review discipline on another family. The small-package unlock notes and the readout standards round out the method.
Small boards compress the wrong things. On a typical TSSOP-20 design the reset line carries a bulk capacitor sized for power-on behaviour in normal operation, and that same capacitance distorts the debug clock’s timing window when the programmer shares the net, which is why so many first attempts to read one of these boards in house produce a no-target-found message from a perfectly healthy part. The fix is physical and small: isolate one component, present the programmer a clean edge, and restore it afterwards. Our fixture notes record which component on which board revision, because the same board design pops up across product lines and the lesson should not be relearned per project. The 16 KB array keeps the electrical side of the session short — a full capture is sixteen pages — so the fixture work dominates the quote, and we are explicit about that split when pricing: customers pay for access, not for bytes. Where the board offers a programming header, the project simplifies further, because the value line’s boot configuration is pin-strapped and readable; where it does not, the two-wire debug interface through the one accessible net is usually sufficient for state analysis even when the full readout needs more. Either way, the analysis comes before the force, and on a part whose entire program fits in sixteen kilobytes, the force option destroys nearly all of the value in one mass erase. There is one more TSSOP-specific habit worth recording: the package’s fine leadframe makes the part easy to reach and equally easy to damage, so boards that may need to run again are documented and rehearsed before work begins. Where the customer has a spare unit, the spare becomes the practice board; where they do not, the quote says so and prices the risk instead of hiding it in the hourly rate.
Send the marking and a photograph of both sides of the board. On TSSOP-20 projects the board photo often decides the quote, because fixture time dominates everything else.