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

docs: Adds description of OpenOCD command to configure custom app image location

Browse source
This commit is contained in:
Alexey Gerenkov 2018-08-16 21:33:23 +03:00
parent 414b84c041
commit ac07c23e37
2 changed files with 20 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
docs/en/api-guides/jtag-debugging/index.rst
View file

@ -281,6 +281,7 @@ This section provides collection of links to all tips and quirks referred to fro
* :ref:`jtag-debugging-tip-breakpoints`
* :ref:`jtag-debugging-tip-where-breakpoints`
* :ref:`jtag-debugging-tip-flash-mappings`
* :ref:`jtag-debugging-tip-why-next-works-as-step`
* :ref:`jtag-debugging-tip-code-options`
* :ref:`jtag-debugging-tip-freertos-support`

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

@ -20,6 +20,25 @@ What else should I know about breakpoints?
Emulating part of hardware breakpoints using software flash ones means that the GDB command ``hb myFunction`` which is invoked for function in flash will use pure hardware breakpoint if it is avalable otherwise one of the 32 software flash breakpoints is used. The same rule applies to ``b myFunction``-like commands. In this case GDB will decide what type of breakpoint to set itself. If ``myFunction`` is resided in writable region (IRAM) software IRAM breakpoint will be used otherwise hardware or software flash breakpoint is used as it is done for ``hb`` command.
.. _jtag-debugging-tip-flash-mappings:
Flash Mappings vs SW Flash Breakpoints
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In order to set/clear software breakpoints in flash, OpenOCD needs to know their flash addresses. To accomplish conversion from the ESP32 address space to the flash one, OpenOCD uses mappings of program's code regions resided in flash. Those mappings are kept in the image header which is prepended to program binary data (code and data segments) and is specific to every application image written to the flash. So to support software flash breakpoints OpenOCD should know where application image under debugging is resided in the flash. By default OpenOCD reads partition table at 0x8000 and uses mappings from the first found application image, but there can be the cases when it will not work, e.g. partition table is not at standard flash location or even there can be multiple images: one factory and two OTA and you may want to debbug any of them. To cover all possible debugging scenarios OpenOCD supports special command which can be used to set arbitrary location of application image to debug. The command has the following format:
``esp32 appimage_offset <offset>``
Offset should be in hex format. To reset to the default behaviour you can specify ``-1`` as offset.
.. note::
Since GDB requests memory map from OpenOCD only once when connecting to it, this command should be specified in one of the TCL configuration files, or passed to OpenOCD via its command line. In the latter case command line should look like below:
``bin/openocd -s share/openocd/scripts -f interface/ftdi/esp32_devkitj_v1.cfg -f board/esp-wroom-32.cfg -c "init; halt; esp32 appimage_offset 0x210000"``
Another option is to execute that command via OpenOCD telnet session and then connect GDB, but it seems to be less handy.
.. _jtag-debugging-tip-why-next-works-as-step:
Why stepping with "next" does not bypass subroutine calls?