31 thoughts on “Eclipse JTAG Debugging the ESP32 with a SEGGER J-Link”

1. Erich,
   great article. I wanted to get JTAG debugging going on my ESP32 for a while now. So today I tried to hook up two JTAG adapters (generic and j-link) up to the JTAG port of my ESP-WROVER. Ran into trouble right away (with both of them!). Could not get the JTAG interface to respond at all. Had to add a pull-up resistor on IO14: JTAG TMS to make it work. Maybe this is the same issue you had with your smaller J-Link EDU mini?

   LikeLike

   Reply ↓

   • Good point, I have to check this out! What did you use as debug probe? The normal J-Link or the PRO?

     LikeLike

     Reply ↓

     • So far my projects centered around Kinetis uC’s, So, most of the time I use the on-board SWD debug interfaces when dealing with our assortment of EVKs.

       But to get the single-step debug going with the ESP32 I tried using the Altera/Intel USB Blaster, and an old Amontec JTAGkey2 we have at the office. At home I tried it with my J-Link Edu. Did not get very far with either.

       Looking at the JTAG interface pins on the ESP32: only two have either a pull-up or pull-down resistor built in (MTDO and MTDI), while neither the MTCK nor the MTMS have any. In my opinion, those should be pulled to safe and steady levels just to avoid floating inputs.

       Seems that on my board (which has the standard ESP32 USB-UART upload port as well) the state of that interface may prevent the JTAG from working… need to hook up my trusty LogicPro16 and investigate.

       LikeLike

       Reply ↓

       • Me too: my projects are mostly around Kinetis.
         I tried adding 10k pull-ups to the JTAG lines as you suggested. But adding a pull-up to the TDI does not let the ESP32 boot. I can add pull-ups to the TDO and TMS, and that still works with the ‘big’ J-Link EDU.
         But it does not work with the J-Link EDU *Mini*, still the same error message from OpenOCD:
         
Warn : Failed to send data to device: LIBUSB_ERROR_TIMEOUT.
Warn : Failed to send data to device: LIBUSB_ERROR_TIMEOUT.
Error: Sending data to device timed out.
Error: transport_write() failed: timeout occurred.
Error: jaylink_jtag_io() failed: timeout occurred.
Error: Failed to fetch AR regs!

         So the J-Link EDU Mini does not work, and I think this might be a problem of OpenOCD. It *does* work with the normal J-Link EDU (non-mini)
         To my understanding and reading the information on the web, the ESP32 has internal pull-ups and pull-downs, so no external resistors should be needed. The Espressif boards with JTAG interface do not have pull resistors too.
         Anyway, thanks for the idea!

         LikeLike

2. The ESP32 Series Datasheet Version 3.1 (covers ESP32-D0WD, ESP32-D0WDQ6, ESP32-D2WD and ESP32-S0WD) states in section 2.4:

   “… During the chip’s system reset release (power-on-reset, RTC watchdog reset and brownout reset), the latches of the strapping pins sample the voltage level as strapping bits of ”0” or ”1”, and hold these bits until the chip is powered down or shut down. The strapping bits configure the device’s boot mode, the operating voltage of VDD_SDIO and other initial system settings. …”

   The important part here is that this happens during specific reset cycles, namely power-on-reset/watchdog reset or brownout reset. During these reset cycles it latches the state of the MTDI pin (GPIO12):

   
Voltage of Internal LDO (VDD_SDIO)

   Pin Default 3.3V 1.8V
MTDI Pull-down 0 1


   So, depending on the ESP32 board or module you are using, you need to determine what kind of SPI FLASH ROM is in use. For my ESP-WROVER this happens to be 3.3V SPI FLASH. The pin therefore needs to see a LOW level during those reset cycles to operate at all.

   To throw another wrinkle in there, the ESP32 contains an EFUSE block that allows overriding some of the strapping pin settings:

   “… • Firmware can configure register bits to change the settings of ”Voltage of Internal LDO (VDD_SDIO)” and ”Timing of SDIO Slave”, after booting. …”

   Just to show that MTDI adds a bit of complexity, the manual goes on to state:

   “… • For ESP32 chips that contain an embedded flash, users need to note the logic level of MTDI. For example, ESP32-D2WD contains an embedded flash that operates at 1.8 V, therefore, the MTDI should be pulled high. …”

   In Appendix A.4.IO_MUX, MTDI is listed as having an internal weak pull-down.

   Of note are the equally important MTCK and MTMS pins, which do not come with any internal pull-up or pull-down resistors at all. Which is probably why ESPRESSIF has (jumper configurable) external 10K pull-down resistor on MTCK, and an external 10K pull-up resitor on MTMS on their ESP-WROVER-KIT board (schematics see JTAG section ESP-WROVER-KIT_V4_1.pdf).

   LikeLike

   Reply ↓

   • Thank you so much for all the detailed information!
     But none of these allowed me to use the SEGGER J-Link, I tried pull resistors in different combinations. Independently, SEGGER has contacted me and I’m exchanging information with them, and potentially we might be able to identify the isse. SEGGER is getting an ESP32 hardware so they could try it out on their side. An early indication could be that the issue is within OpenOCD not using the correct way to get the data through USB. Once I know more, I plan to post an update.

     LikeLike

     Reply ↓

     • Erich,

       LikeLike

       Reply ↓

       • yes?

         LikeLike

     • Hi Erich! Did you ever get this working? I’m just getting into the ESP32 world, and I’m figuring out which way I want to approach debugging.

       LikeLike

       Reply ↓

       • Hi Ed,
         yes, it works very well with the circuit and connection shown in this article. It only does not work with the J-Link EDU (I had reported this to SEGGER).
         See as well https://mcuoneclipse.com/2019/10/20/jtag-debugging-the-esp32-with-ft2232-and-openocd/ for a different way to debug it.

         Erich

         LikeLike

3. Pingback: JTAG Debugging the ESP32 with FT2232 and OpenOCD | MCU on Eclipse

4. Hi Erich, thank you so much for the great post!

   I am currently laying out a board with the ESP 32, and this is the first time I’ve ever had to design a board with a JTAG header. I am a little confused about your photo where you highlighted the Segger J-Link pins that use used in yellow; you have highlighted both the nTRST and RESET signals, however, your photo seems to show that the nTRST is not used. Did you use both of these pins?

   As an aside, I honestly can’t tell what the difference is between them from the description on Segger’s website:

   nTRST — > Output –> JTAG Reset.
   Output from J-Link to the Reset signal of the target JTAG port. Typically connected to nTRST of the target CPU. This pin is normally pulled HIGH on the target to avoid unintentional resets when there is no connection.

   nRESET –> I/O –> Target CPU reset signal.
   Typically connected to the RESET pin of the target CPU, which is typically called “nRST”, “nRESET” or “RESET”. This signal is an active low signal.

   I am a little lost on what to do!

   LikeLike

   Reply ↓

   • Hi Erich,

     By the way, back in May you responded to me with:

     > It only does not work with the J-Link EDU

     You are showing the a J-Link EDU connected in the photos in your post. Do you mean the EDU mini? I have a regular J-Link EDU.

     Thanks!

     LikeLike

     Reply ↓

     • Hi Ed,
       I’m sorry, I missed to add the ‘mini’ to that sentence (fixed now). It works for me with the ‘normal’/’big’/’grey’ J-Link EDU as in the pictures. But it did *not* work with the small EDU mini version.
       Erich

       LikeLike

       Reply ↓

   • Hi Ed,
     It means that the ‘reset’ pin of the J-Link shall be connected to the reset pin of the target.
     See https://mcuoneclipse.files.wordpress.com/2019/09/ttgo-micro-32-jtag-connection.png
     I hope this helps,
     Erich

     LikeLike

     Reply ↓

5. Erich,
   Thanks so much for the article! I believe I have this ‘mostly’ working. Except that it is not breaking (or not getting to) app_main. It breaks on this line of code:
   } else if (default_chip.size > g_rom_flashchip.chip_size) {
   This is inside the esp_flash_init_default_chip() function.

   Any idea what I might have done wrong?

   LikeLike

   Reply ↓

   • if you press continue, then it runs to main?
     So it must be something stopping the debugger. Can you check the Console view output in Eclipse for the output/logs of the J-Link? It should tell you why it stopped. Or check the GDB logs (see https://mcuoneclipse.com/2016/07/01/board-bring-up-tips-gdb-logs-and-traces-in-eclipse/). Anything useful there?

     LikeLike

     Reply ↓

     • Erich,
       -If I hit run, it keeps breaking at this same place. I’ve made sure all breakpoints are removed and I still see the same thing.
       -I don’t see much in the logs that is helpful to me. Do you see anything thing that stands out to you?

       ** Programming Finished **
       ** Verify Started **
       Info : Target halted. PRO_CPU: PC=0x4009171A (active) APP_CPU: PC=0x40000400
       read 732400 bytes from file C:/_DEV/REDACTED/3_Firmware/ESP_Now/build/ESP32_Now.bin and flash bank 0 at offset 0x00010000 in 17.194674s (41.596 KiB/s)
       contents match
       ** Verified OK **
       Info : Target halted. PRO_CPU: PC=0x400E241C (active) APP_CPU: PC=0x400812F0
       Info : Detected debug stubs @ 3ffb4288 on core0 of target ‘esp32’
       Info : dropped ‘gdb’ connection
       Info : accepting ‘gdb’ connection on tcp/3333
       Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
       Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
       Info : esp32: Debug controller 0 was reset (pwrstat=0x5F, after clear 0x0F).
       Info : esp32: Core 0 was reset (pwrstat=0x5F, after clear 0x0F).
       Info : Target halted. PRO_CPU: PC=0x5000004B (active) APP_CPU: PC=0x00000000
       Info : esp32: Core 0 was reset (pwrstat=0x1F, after clear 0x0F).
       Info : esp32: Debug controller 1 was reset (pwrstat=0x5F, after clear 0x0F).
       Info : esp32: Core 1 was reset (pwrstat=0x5F, after clear 0x0F).
       Info : Target halted. PRO_CPU: PC=0x40000400 (active) APP_CPU: PC=0x40000400
       Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
       Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
       Info : esp32: Debug controller 0 was reset (pwrstat=0x5F, after clear 0x0F).
       Info : esp32: Core 0 was reset (pwrstat=0x5F, after clear 0x0F).
       Info : Target halted. PRO_CPU: PC=0x5000004B (active) APP_CPU: PC=0x00000000
       Info : esp32: Core 0 was reset (pwrstat=0x1F, after clear 0x0F).
       Info : esp32: Debug controller 1 was reset (pwrstat=0x5F, after clear 0x0F).
       Info : esp32: Core 1 was reset (pwrstat=0x5F, after clear 0x0F).
       Info : Target halted. PRO_CPU: PC=0x40000400 (active) APP_CPU: PC=0x40000400
       ** Programming Started **
       auto erase enabled
       Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1071). Workaround: increase “set remotetimeout” in GDB
       Info : Target halted. PRO_CPU: PC=0x4009171A (active) APP_CPU: PC=0x40000400
       Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1581). Workaround: increase “set remotetimeout” in GDB
       Info : Target halted. PRO_CPU: PC=0x4009171A (active) APP_CPU: PC=0x40000400
       wrote 733184 bytes from file C:/_DEV/REDACTED/3_Firmware/ESP_Now/build/ESP32_Now.bin in 22.254133s (32.174 KiB/s)
       ** Programming Finished **
       ** Verify Started **
       Info : Target halted. PRO_CPU: PC=0x4009171A (active) APP_CPU: PC=0x40000400
       read 732400 bytes from file C:/_DEV/REDACTED/3_Firmware/ESP_Now/build/ESP32_Now.bin and flash bank 0 at offset 0x00010000 in 17.160501s (41.679 KiB/s)
       contents match
       ** Verified OK **
       Info : Detected debug stubs @ 3ffb4288 on core0 of target ‘esp32’
       Info : Target halted. PRO_CPU: PC=0x400E241C (active) APP_CPU: PC=0x400812E7

       LikeLike

       Reply ↓

       • And here’s the last bit of my GDB log:
         [message truncated to 5 lines. More lines can be set in the Preference->Debug->GDB eclipse preference page.]
         489,703 (gdb)
         489,709 91^done,locals=[{name=”cfg”,value=”{host_id = SPI1_HOST, cs_num = 0, iomux = false, input_de\
         lay_ns = 0, speed = ESP_FLASH_40MHZ}”},{name=”err”,value=”0″}]
         489,709 (gdb)
         489,739 92-var-update 1 var1
         489,739 93-var-update 1 var2
         489,749 92^done,changelist=[]
         489,749 (gdb)
         489,750 93^done,changelist=[]
         489,750 (gdb)
         489,767 94-thread-info 7
         489,768 95-thread-info 8
         489,768 96-thread-info 9
         489,815 94^done,threads=[{id=”7″,target-id=”Thread 1073459512″,details=”Name: dport”,frame={level=”0\
         “,addr=”0x40093184″,func=”vPortTaskWrapper”,args=[{name=”pxCode”,value=”0x0″},{name=”pvParameters”,v\
         alue=”0x0″}],file=”C:/_DEV/_Tools/ESP-IDF/Tools/components/freertos/port.c”,fullname=”C:\\_DEV\\_Too\
         ls\\ESP-IDF\\Tools\\components\\freertos\\port.c”,line=”142″},state=”stopped”}]
         489,815 (gdb)
         489,840 95^done,threads=[{id=”8″,target-id=”Thread 1073412788″,details=”Name: esp_timer”,frame={leve\
         l=”0″,addr=”0x40093184″,func=”vPortTaskWrapper”,args=[{name=”pxCode”,value=”0x0″},{name=”pvParameter\
         s”,value=”0x0″}],file=”C:/_DEV/_Tools/ESP-IDF/Tools/components/freertos/port.c”,fullname=”C:\\_DEV\\\
         _Tools\\ESP-IDF\\Tools\\components\\freertos\\port.c”,line=”142″},state=”stopped”}]
         489,840 (gdb)
         489,851 96^done,threads=[{id=”9″,target-id=”Thread 1073458380″,details=”Name: ipc1, State: Running @\
         CPU1″,frame={level=”0″,addr=”0x400812e7″,func=”start_cpu1_default”,args=[],file=”C:/_DEV/_Tools/ESP-\
         IDF/Tools/components/esp32/cpu_start.c”,fullname=”C:\\_DEV\\_Tools\\ESP-IDF\\Tools\\components\\esp3\
         2\\cpu_start.c”,line=”456″},state=”stopped”}]
         489,851 (gdb)

         LikeLike

       • unfortunately this does not show anything useful why the target has halted.

         LikeLike

6. Thanks for the blog. Working fine with ESP 32 DEVKIT C.

   LikeLiked by 1 person

   Reply ↓

   • Great, thanks for confirming it.

     LikeLike

     Reply ↓

7. Erich, nice work. Thanks.
   I’ve tried to install the Expressif IDF Plugins for Eclipse in MCUXpresso IDE version 11.3.1 but it fails with message “Missing requirement: Espressif IDF Plugins for Eclipse 2.1.1.202106040310 (com.espressif.idf.feature.feature.group 2.1.1.202106040310) requires ‘org.eclipse.equinox.p2.iu; org.eclipse.cdt.cmake.is.core 0.0.0’ but it could not be found”.
   Have you managed to installing the plug-in in MCUXpresso IDE version 11.3.1?

   LikeLike

   Reply ↓

   • Hi Victor,
     no, I did not try to install the Espressif IDF plugin in Eclipse: I’m using normal ‘make’ projects and then call the idf.py from Eclipse. That worked very well.

     LikeLike

     Reply ↓

     • Hi Erich,
       I followed the steps from your post https://mcuoneclipse.com/2019/08/18/building-and-flashing-esp32-applications-with-eclipse/ and managed to setup the projects for compiling and flashing. Idf-tools version 4.3 packs a batch file prepared for setting all required environment variables so I simply launched the batch and launched the MCUXpresso IDE from there. No need to make permanent PATH adjustments.
       The sdkconfig.h file is still marked as unresolved external, but the rest I tested is working fine for me now.
       The built-in terminal also worked well.
       One note, a preconfigured Eclipse copy is packed with the tools package that works out of the box. With version 4.2, which is the one I use on Linux, I installed and configured Eclipse manually, yet it was easy and smooth following their guide.
       Thanks again for this great work you do and for sharing it.

       LikeLiked by 1 person

       Reply ↓

       • Hi Victor,
         many thanks for the feedback, appreciated. Yes, permanent PATH changes are not good and I avoid that whenever possible. For me the easiest way is to start the IDF environment (ESP-IDF Command Prompt) on Windows and launch Eclipse from there. The IDF command prompt sets up all the correct environment locally, so I don’t have to change anything.

         LikeLike

   • Don’t know how much ESPRESSIF relies on having a plain-vanilla Eclipse installation (could be the MCUXpresso flavour interferes due to some NXP customizations?). Once I had tried the VSC/PlatformIO combination as an alternate ESP32 IDE, it quickly became my preferred choice. Might be worth checking out if you can’t resolve this, or don’t fancy installing another Eclipse IDE copy.

     LikeLiked by 1 person

     Reply ↓

     • I believe it is more of a problem of the Espressif plugin with its dependency to CMake: I was never able to have a good CMake working environment inside Eclipse. I agree that VSC is a very good alternative, and it supports CMake out of the box. But PlatformIO is not needed at all (actually it it did not install successfully on my machine). Not sure if you have seen my series on VSC already? https://mcuoneclipse.com/2021/06/02/visual-studio-code-for-c-c-with-arm-cortex-m-part-7-freertos/

       LikeLike

       Reply ↓

       • Glad to know I wasn’t the only one fighting with it.You are correct in that PIO is not absolutely essential. I usually recommend PIO to point out a simple upgrade path/alternative to the Arduino IDE, which for some reason most stumble upon first when starting out with micro-controllers or the ESP32. I did not have any issues during the PIO installation and found the breath of supported frameworks/platforms/boards astounding. This to me is the greatest benefit, rather than having to deal with multiple vendor provided IDEs for each architecture. And yes, I’ve been following your series about the VSC with great interest (good job by the way, keep the updates comping please!) as I am currently working on a project that involves combining working in both, the MCUXpresso IDE and the VSC.

         LikeLiked by 1 person

       • Hi Ralf,
         great that you are already aware of the series! I have limited time for new articles because it is the ‘hot’ phase with lots of exams at the university which keeps me very busy, but I plan to continue the series as soon as possible. PIO is for sure great for everyone coming from Arduino. As for myself, I’m not coming from the Arduino land so this did not show any benefit to me. Yes, PIO seems to support lots of platforms but that was not relevant for me: I tried to use it for my realtime and industrial applications and somehow it did not fit.

         LikeLike

     • I have a Debian 10 Linux machine, in fact a VM, with esp-idf installed and I’m using Eclipse with the Expressif IDF Plugins working with no issue so far. I have not configured the HW debugger there.
       I also tried VSC + PlatformIO on windows and it did not work for me. Neither basing it in esp-idf tools nor basing it in the Arduino tools.
       Probably I’m too used to the full IDEs I know (CodeWarrior, KDS, Eclipse, IAR, uVision, etc.) that failing in my first and only attempt to get VSC+PIO working just discouraged me from continuing with that line of doing.

       LikeLiked by 1 person

       Reply ↓

What do you think? Cancel reply

Enter your comment here...

Fill in your details below or click an icon to log in:

Email (required) (Address never made public)

Name (required)

Website

You are commenting using your WordPress.com account. ( Log Out /  Change )

You are commenting using your Google account. ( Log Out /  Change )

You are commenting using your Twitter account. ( Log Out /  Change )

You are commenting using your Facebook account. ( Log Out /  Change )

Cancel

Connecting to %s

Notify me of new comments via email.

Notify me of new posts via email.

Δ

This site uses Akismet to reduce spam. Learn how your comment data is processed.