Updated links to binary distributions of OpenOCD

docs/api-guides/hlinterrupts.rst

@@ -4,10 +4,7 @@ High-Level Interrupts
 .. toctree::
    :maxdepth: 1
 
-The Xtensa architecture has support for 32 interrupts, divided over 8 levels, plus an assortment of exceptions. On the ESP32, the interrupt
+The Xtensa architecture has support for 32 interrupts, divided over 8 levels, plus an assortment of exceptions. On the ESP32, the interrupt mux allows most interrupt sources to be routed to these interrupts using the :doc:`interrupt allocator <../api-reference/system/intr_alloc>`. Normally, interrupts will be written in C, but ESP-IDF allows high-level interrupts to be written in assembly as well, allowing for very low interrupt latencies.
-mux allows most interrupt sources to be routed to these interrupts using the :doc:`interrupt allocator <api/system/intr_alloc>`. Normally,
-interrupts will be written in C, but ESP-IDF allows high-level interrupts to be written in assembly as well, allowing for very low interrupt
-latencies.
 
 Interrupt Levels
 ----------------

docs/api-guides/jtag-debugging/index.rst

@@ -46,7 +46,7 @@ This document provides a guide to installing OpenOCD for ESP32 and debugging usi
 How it Works?
 -------------
 
-The key software and hardware to perform debugging of ESP32 with OpenOCD over JTAG (Joint Test Action Group) interface is presented below and includes **xtensa-esp32-elf-gdb debugger**, **OpenOCD** on chip debugger and **JTAG adapter** connected to **ESP32** target.
+The key software and hardware to perform debugging of ESP32 with OpenOCD over JTAG (Joint Test Action Group) interface is presented below and includes **xtensa-esp32-elf-gdb debugger**, **OpenOCD on chip debugger** and **JTAG adapter** connected to **ESP32** target.
 
 .. figure:: ../../_static/jtag-debugging-overview.jpg
     :align: center
@@ -59,7 +59,7 @@ Under "Application Loading and Monitoring" there is another software and hardwar
 
 Debugging using JTAG and application loading / monitoring is integrated under the `Eclipse <http://www.eclipse.org/>`_ environment, to provide quick and easy transition from writing, compiling and loading the code to debugging, back to writing the code, and so on. All the software is available for Windows, Linux and MacOS platforms.
 
-If the :doc:`ESP32 WROVER KIT <../../hw-reference/modules-and-boards>` is used, then connection from PC to ESP32 is done effectively with a single USB cable thanks to FT2232H chip installed on WROVER, which provides two USB channels, one for JTAG and the second for JTAG connection.
+If the :doc:`ESP32 WROVER KIT <../../hw-reference/modules-and-boards>` is used, then connection from PC to ESP32 is done effectively with a single USB cable thanks to FT2232H chip installed on WROVER, which provides two USB channels, one for JTAG and the second for UART connection.
 
 Depending on user preferences, both `debugger` and `make` can be operated directly from terminal / command line, instead from Eclipse.
 
@@ -201,10 +201,13 @@ Another option is to write application image to flash using OpenOCD via JTAG wit
     cd ~/esp/openocd-esp32
     bin/openocd -s share/openocd/scripts -f interface/ftdi/esp32_devkitj_v1.cfg -f board/esp-wroom-32.cfg -c "program_esp32 filename.bin 0x10000 verify exit"
 
-OpenOCD flashing command ``program_esp32`` has the following format ``program_esp32 <image_file> <offset> [verify] [reset] [exit]``.
+OpenOCD flashing command ``program_esp32`` has the following format:
- - ``image_file`` - path to program image file
+
- - ``offset`` - offset in flash bank to write image
+``program_esp32 <image_file> <offset> [verify] [reset] [exit]``
- - ``verify`` - Optional. Verify written flash contents after writing.
+
+ - ``image_file`` - Path to program image file.
+ - ``offset`` - Offset in flash bank to write image.
+ - ``verify`` - Optional. Verify flash contents after writing.
  - ``reset`` - Optional. Reset target after programing.
  - ``exit`` - Optional. Finally exit OpenOCD.
 

docs/api-guides/jtag-debugging/setup-openocd-linux.rst

@@ -8,12 +8,12 @@ Setup OpenOCD
 
 OpenOCD for 64-bit Linux is available for download from Espressif website:
 
-https://dl.espressif.com/dl/openocd-esp32-linux64-ed7b1a9.tar.gz
+https://dl.espressif.com/dl/openocd-esp32-linux64-a859564.tar.gz 
 
 Download this file, then extract it in ``~/esp/`` directory::
 
     cd ~/esp
-    tar -xzf ~/Downloads/openocd-esp32-linux64-ed7b1a9.tar.gz
+    tar -xzf ~/Downloads/openocd-esp32-linux64-a859564.tar.gz 
 
 
 Next Steps

docs/api-guides/jtag-debugging/setup-openocd-macos.rst

@@ -8,12 +8,12 @@ Setup OpenOCD
 
 OpenOCD for MacOS is available for download from Espressif website:
 
-https://dl.espressif.com/dl/openocd-esp32-macos-ed7b1a9.tar.gz
+https://dl.espressif.com/dl/openocd-esp32-macos-a859564.tar.gz 
 
 Download this file, then extract it in ``~/esp`` directory::
 
     cd ~/esp
-    tar -xzf ~/Downloads/openocd-esp32-macos-ed7b1a9.tar.gz
+    tar -xzf ~/Downloads/openocd-esp32-macos-a859564.tar.gz 
 
 
 Next Steps

docs/api-guides/jtag-debugging/setup-openocd-windows.rst

@@ -8,7 +8,7 @@ Setup OpenOCD
 
 OpenOCD for Windows / MSYS2 is available for download from Espressif website:
 
-https://dl.espressif.com/dl/openocd-esp32-win32-ed7b1a9.zip
+https://dl.espressif.com/dl/openocd-esp32-win32-a859564.zip
 
 Download this file and extract ``openocd-esp32`` folder inside to ``~/esp/`` directory.
 

docs/api-guides/jtag-debugging/tips-and-quirks.rst

@@ -64,7 +64,7 @@ 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
-* ``hb app_main`` — insert a 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``.
 
@@ -74,7 +74,7 @@ On startup, debugger is issuing sequence of commands to reset the chip and halt
 Configuration of OpenOCD for specific target
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-OpenOCD needs to be told what JTAG adapter **interface** to use, as well as what type of **board** and processor the JTAG adapter is connected to. To do so, use existing configuration files located in OpenOCD's ``/share/openocd/scripts/interface`` and ``/share/openocd/scripts/board`` folders. 
+OpenOCD needs to be told what JTAG adapter **interface** to use, as well as what type of **board** and processor the JTAG adapter is connected to. To do so, use existing configuration files located in OpenOCD's ``share/openocd/scripts/interface`` and ``share/openocd/scripts/board`` folders. 
 
 For example, if you connect to ESP-WROVER-KIT with ESP-WROOM-32 module installed (see section :doc:`ESP32 WROVER KIT <../../hw-reference/modules-and-boards>`), use the following configuration files:
 
@@ -121,7 +121,7 @@ Power supply voltage of ESP32's SPI flash chip
 
     set ESP32_FLASH_VOLTAGE 1.8
 
-Comment out this line to set 3.3V, ref: :ref:`jtag-debugging-tip-code-flash-voltage`.
+Comment out this line to set 3.3V, ref: :ref:`jtag-debugging-tip-code-flash-voltage`
 
 
 Configuration file for ESP32 targets