What the developer wrote
Authored by Niklas Dusenlund
jlink-scripts: reset before load
When using the watchdog it became clear that one must reset the CPU
before loading a new FW. It behaved very strange with the old order of
things.
What changed, and why it matters
This commit changes the order of operations in two developer-only GDB scripts used with J-Link debuggers. Previously the scripts loaded new firmware onto the device and then reset the CPU; now they reset the CPU first and then load the firmware. The change is described as a reliability fix for odd behavior seen when the device's watchdog timer is enabled. It only affects how engineers flash firmware during development/debugging and does not change any firmware code, cryptography, or user-facing behavior.
No security action required. Treat as a normal developer-experience/flash-script reliability improvement.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The patch modifies scripts/jlink-bootloader.gdb and scripts/jlink.gdb, moving the ‘monitor reset’ command to run before ‘load’ instead of after. The commit message and inline comments explain that with the watchdog enabled, loading firmware before resetting produced strange/unreliable behavior, and Segger’s own J-Link GDB Server documentation example also resets before loading. No firmware source, bootloader, or runtime logic is altered.
Changed components
scripts/jlink-bootloader.gdbscripts/jlink.gdbInspect captured patch +12 / −4
diff --git a/scripts/jlink-bootloader.gdb b/scripts/jlink-bootloader.gdb
index a7629aa..514c3e4 100644
--- a/scripts/jlink-bootloader.gdb
+++ b/scripts/jlink-bootloader.gdb
@@ -1,12 +1,16 @@
# Connect to jlink gdb server
target extended-remote :2331
-# load the firmware into ROM
-load
+# It seems more reliable to reset the chip before loading the new firmware. It
+# is also how they do it in the example in the wiki:
+# https://kb.segger.com/J-Link_GDB_Server#Console
# Reset the CPU
monitor reset
+# load the firmware into ROM
+load
+
#break Reset_Handler
#break HardFault_Handler
#break NMI_Handler
diff --git a/scripts/jlink.gdb b/scripts/jlink.gdb
index 4a9cf9f..899c135 100644
--- a/scripts/jlink.gdb
+++ b/scripts/jlink.gdb
@@ -1,12 +1,16 @@
# Connect to jlink gdb server
target extended-remote :2331
-# load the firmware into ROM
-load
+# It seems more reliable to reset the chip before loading the new firmware. It
+# is also how they do it in the example in the wiki:
+# https://kb.segger.com/J-Link_GDB_Server#Console
# Reset the CPU
monitor reset
+# load the firmware into ROM
+load
+
# Set VTOR (Vector Table Offset Register) to where the firmware is located
set *(uint32_t*)0xE000ED08=0x10000
# Set stack pointer to initial stack pointer according to exception table.
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.