docs/jtag: use ‘flushregs’ instead of ‘x $a1=0” in gdbinit

The old command caused was incorrect (x is “examine”, not “execute”)
and caused GDB register update only by chance. This replaces it with
“flushregs” command which purpose is exactly that — force GDB to
fetch registers from the remote.

diff --git a/docs/_static/hw-debugging-startup-tab.jpg b/docs/_static/hw-debugging-startup-tab.jpg
index 667d672f396f8a8602144d249ee3ccd2d064626a..bad2d593834ee650802ab869fc7c4d0e731a25f6 100644 (file)
Binary files a/docs/_static/hw-debugging-startup-tab.jpg and b/docs/_static/hw-debugging-startup-tab.jpg differ

diff --git a/docs/en/api-guides/jtag-debugging/tips-and-quirks.rst b/docs/en/api-guides/jtag-debugging/tips-and-quirks.rst
index bc81dbd6f5c73e3920600bf2bf07e3e18631ca56..3adfa0d9380b4adeec0e6d75b785c718bc949edc 100644 (file)
--- a/docs/en/api-guides/jtag-debugging/tips-and-quirks.rst
+++ b/docs/en/api-guides/jtag-debugging/tips-and-quirks.rst
@@ -81,8 +81,8 @@ What is the meaning of debugger's startup commands?
 On startup, debugger is issuing sequence of commands to reset the chip and halt it at specific line of code. This sequence (shown below) is user defined to pick up at most convenient / appropriate line and start debugging. 
 
 * ``mon reset halt`` — reset the chip and keep the CPUs halted
+* ``flushregs`` — monitor (``mon``) command can not inform GDB that the target state has changed. GDB will assume that whatever stack the target had before ``mon reset halt`` will still be valid. In fact, after reset the target state will change, and executing ``flushregs`` is a way to force GDB to get new state from the target.
 * ``thb app_main`` — insert a temporary hardware breakpoint at ``app_main``, put here another function name if required
-* ``x $a1=0`` — this is the tricky part. As far as we can tell, there is no way for a ``mon`` command to tell GDB that the target state has changed. GDB will assume that whatever stack the target had before ``mon reset halt`` will still be valid. In fact, after reset the target state will change and executing ``x $a1=0`` is a way to force GDB to get new state from the target.
 * ``c`` — resume the program. It will then stop at breakpoint inserted at ``app_main``.
 
 

diff --git a/docs/en/api-guides/jtag-debugging/using-debugger.rst b/docs/en/api-guides/jtag-debugging/using-debugger.rst
index e42210aed6f34cbceb1f09ef12903f8fa754745d..2c8e5d7a066133ab9fc5552eec5fac36cdd77f55 100644 (file)
--- a/docs/en/api-guides/jtag-debugging/using-debugger.rst
+++ b/docs/en/api-guides/jtag-debugging/using-debugger.rst
@@ -48,7 +48,7 @@ Once installation is complete, configure debugging session following steps below
 
         Configuration of GDB Hardware Debugging - Debugger tab
 
-8.  The last tab to that requires changing of default configuration is "Startup". Under "Initialization Commands" uncheck "Reset and Delay (seconds)" and "Halt"". Then, in entry field below, type ``mon reset halt`` and ``x $a1=0`` (in two separate lines).
+8.  The last tab to that requires changing of default configuration is "Startup". Under "Initialization Commands" uncheck "Reset and Delay (seconds)" and "Halt"". Then, in entry field below, type ``mon reset halt`` and ``flushregs`` (in two separate lines).
 
     .. note::
         If you want to update image in the flash automatically before starting new debug session add the following lines of commands at the beginning of "Initialization Commands" textbox::
@@ -113,8 +113,8 @@ Command Line
 
         target remote :3333
         mon reset halt
+        flushregs
         thb app_main
-        x $a1=0
         c
 
     Save this file in current directory.