Many engineers have encountered a situation where firmware is downloaded to a board but the MCU does not start. Several issues can cause this behavior. The following are common causes to check.
Incorrect BOOT pin level
On GD32 MCUs the BOOT pin determines the startup mode. Typically, when BOOT0 is pulled low the MCU boots from internal flash. If the BOOT pin level is incorrect, the MCU will not execute the downloaded program.
Is NRST released (pulled high)?
NRST is the MCU reset pin. If the reset pin is not released (pulled high), the program will not start. The reset pin behavior is related to the power supply and associated circuitry. Typically NRST is released about 2 ms after power-on reset (POR). If NRST is not released, further check the power sequence and reset circuit.
Are VDD and VDDA within the operating range?
Designers often focus on VDD, but VDDA is also critical. Ensure both VDD and VDDA reach the chip's specified operating voltage range; otherwise the MCU may not run correctly.
Does the oscillator match the firmware configuration?
If the MCU is effectively overclocked due to a mismatch between the actual crystal/oscillator frequency and the firmware clock configuration, it can behave erratically or fail to start. Verify that the oscillator frequency used on the board matches the clock configuration in firmware.
Firmware does not match the actual chip model or variant
For example, the GD32F30x firmware package covers GD32F303, F305, F307 and other variants selected via macros. These variants can differ in clock and peripheral details. If the firmware is configured for the wrong variant, the program may fail during clock initialization or other early-stage code.
If the issue is still unresolved, enter the debugger and step through startup. Do not assume the application code is faultless; the root cause can be as simple as a typo. Software debug techniques can help isolate where startup fails.