Crash_Override/OVMS3-idf
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Merge branch 'doc/jtag_startup_command_fix' into 'master'

Browse source 
docs/jtag: use 'flushregs' instead of 'x $a1=0' in gdbinit

See merge request idf/esp-idf!2520
This commit is contained in:
Angus Gratton 2018-06-08 15:15:29 +08:00
commit bcd4fb9944
3 changed files with 3 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

BIN
docs/_static/hw-debugging-startup-tab.jpg vendored
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 70 KiB

After

Width:  |  Height:  |  Size: 67 KiB

2
docs/en/api-guides/jtag-debugging/tips-and-quirks.rst
View file

@ -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. 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 * ``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 * ``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``. * ``c`` — resume the program. It will then stop at breakpoint inserted at ``app_main``.

4
docs/en/api-guides/jtag-debugging/using-debugger.rst
View file

@ -48,7 +48,7 @@ Once installation is complete, configure debugging session following steps below
Configuration of GDB Hardware Debugging - Debugger tab 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:: .. 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:: 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 target remote :3333
mon reset halt mon reset halt
flushregs
thb app_main thb app_main
x $a1=0
c c
Save this file in current directory. Save this file in current directory.