- This topic has 10 replies, 2 voices, and was last updated 6 years, 6 months ago by
.
-
Posts
-
I’m trialing VisualGDB for use with the ESP32-Wrover-Kit V2 (with ESP-Wroom-32 module) and using the onboard FT2232 JTAG. I’m having trouble with the OpenOCD config file. This should be a very standard hardware setup but I can’t find a config file, so I’ll post here because I probably won’t be the last person to google this problem. The chip gets itself into a state that it is very hard to get out of (but I won’t clutter this post with details).
Here is the problematic config I’m using, that works when it works, but sometimes lands the chip in a permanently dodgy state:
interface ftdi ftdi_device_desc "Dual RS232-HS" ftdi_vid_pid 0x0403 0x6010 ftdi_layout_init 0x0028 0x002b ftdi_layout_signal nTRST -data 0x0020 ftdi_layout_signal SWD_EN -data 0 ftdi_layout_signal nSRST -data 0
Could Sysprogs check against the schematic and post a corrected config file content? The schematic of the dev board is here https://dl.espressif.com/dl/schematics/ESP-WROVER-KIT_SCH-2.pdf
A second question would be, should the nTRST pin be jumpered (to EN) – there seems to be differing opinions on that, or whether only the four JTAG pins should be jumpered.
Just a note that the symptoms of my problem are very similar to those of https://sysprogs.com/w/forums/topic/unable-to-flash-esp32-wroom/ but the problem itself appears to be unrelated.
Attaching a text file with output of OpenOCD test of the config, and the error information output provided by VisualGDB upon failure.
Hi,
Sorry, unfortunately checking exact configurations against board schematics goes beyond the scope of our technical support, however we can point you to the most likely cause of the problem.
The following line from the error log suggests that the order of scripts and initialization commands might be wrong:
Error: The 'mww' command must be used after 'init'.
Please try starting with the default settings for ESP32 debugging, ensure that you get a different error (e.g. ‘all bits are zero or one’) and then try modifying the ftdi configuration file to specify your layout.
We have also recently received the ESP-WROOM-32 module (not the WROVER board though) and will be publishing a tutorial showing how to program it over JTAG with Olimex ARM-USB-OCD-H in the next few weeks. You could simply wait till we publish that tutorial and use the schematics from it as a reference.
I retract the original question. The OpenOCD config is not causing the problem (although it contains unnecessary lines). The problem is that the ESP32 toolchain provided for use with VisualGDB is completely unstable. Somehow I must have lucked on a working combination when I started, but after updating Visual GDB to 5.3 and the toolchain to 5.2.0-r4 my installation is completely hosed and I can’t seem to recover it. Building/flashing with Espressif’s command line tools recovers the ESP32 module, which allows it to be flashed exactly once using the VisualGDB toolchain.
The problems I’ve found are too numerous to list here but include: The toolchain’s hello_world project will not build due to syntax errors; When the project does build it flashes something incorrectly which results in the CPU1 reset problem, and flashing works no more; VisualGDB trial will not uninstall (in order to downgrade version) without a license.rtf file; The toolchain is installed in the default C:\SysGCC\esp32 directory, but the build looks for the bin directory in the root of the drive the project is on (D:\); etc. In case it’s relevant, I’m using Microsoft Visual Studio Professional 2017, Version 15.3.5.
I’m happy to work with Sysprogs to help sort out these problems if the help is wanted; please PM me or reply here.
Hi,
Sorry for the confusion. The new toolchains based on ESP-IDF 2.0 and later are only compatible with VisualGDB 5.3 (we had to add a few workarounds in order to support the new Cygwin-based build system). VisualGDB 5.2 should not even show those toolchains in the download list, however if you installed them via v5.3 and then downgraded to v5.2, this would cause multiple weird problems.
Using an older toolchain with a new ESP-IDF would not work either as Espressif changed the clock initialization sequence in the new bootloader that causes the old FLASH programming code to hang.
Hence please try updating to VisualGDB 5.3 and the latest ESP32 toolchain and let us know if you still experience any troubles so that we could help you.
- Installed VisualGDB-5.3-rc1 and esp32-gcc5.2.0-r4 on Visual Studio Professional 2017 Version 15.3.5 using msi/exe files downloaded from the website, checked their installation with VS GUI, all seems fine.
- Tried to create a new hello_world project using the wizard. First problem/bug: When selecting the “Debug Method” I tried to select my own .cfg script which I had previously gotten working. Under “JTAG/SWD programmer” an error icon is displayed with the text “(unspecified)”, at the bottom of the dialog is another error icon with the text “Invalid or missing interface script”, and the “Finish” button is greyed out so I cannot continue. It looks like this version of the toolchain does not allow the selection of one’s own script file.
- What this version of the toolkit does have is an interface script “ftdi/esp32_devkitj_v1.cfg”. Upon inspection it looks like this should do the job; if not, I’ll have to modify it in place. “Test” works, I “Finish” creating the project. I close and reopen VS for good measure, checking the project into revision control.
- I reopen VS, open the solution. Trying to compile (Debug) I almost immediately get compile errors. See attached build log. I don’t know what is wrong. Could you please check using the aforementioned version combination and see if you get the same error, or let me know what I am doing wrong?
Hi,
Looks like your toolchain installation might have gotten corrupt (mixed old/new headers). Please try deleting it and doing a clean install (VisualGDB 5.3 deletes the old toolchain directory when updating, however VisualGDB 5.2 does not).
The latest toolchain does include the “ftdi/esp32_devkitj_v1.cfg” file. Please ensure that your settings look like shown below:
Deleting the toolchain directory completely seems to have done the trick, although I had tried that previously a couple of times without success. There are a couple of issues still, which I’ll describe below, but I’m now able to flash in debug/release and also to step through the code. Thank you for your help and a couple of license purchases will be forthcoming.
The answer to my original question for those who find this on Google, the OpenOCD config file contents to use with the ESP32-WROVER-KIT, is:
interface ftdi ftdi_vid_pid 0x0403 0x6010 ftdi_channel 0 ftdi_layout_init 0x0008 0x000b reset_config none
This is now provided as part of the VisualGDB toolchain for ESP32 as “ftdi/esp32_devkitj_v1.cfg”.
The issues I still see FYI:
- When testing the OpenOCD connection to the JTAG it fails, even after restart of everything. This I find odd, as this same setup (with a presumably corrupt toolchain) worked yesterday, and furthermore the JTAG works for flash/debug. I’ve attached the output in “OpenOCD.txt”.
- There is clearly some issue with the VisualGDB software for updating the toolchain. I suspect that it has a problem deleting or replacing some files/directories, as I struggled to do this manually myself, and that despite not having started Visual Studio since rebooting my PC. A further reboot and I could delete everything, but clearly some background process was locking some files. I’m sorry I cannot provide any more information.
- Flashing still often fails. Sometimes this is noted as a “known OpenOCD” bug, and sometimes not. I’ve attached the error output in “flash1.txt” and “flash2.txt”.
Perhaps one further question: Would you recommend a different debugging solution (alternative to OpenOCD) to use with VisualGDB and the ESP32 if stable debugging functionality is the primary goal?
Hi,
It is hard to say why deleting the toolchain directory did not help before. Most likely some combination of installing different toolchains and VisualGDB versions left some files open and they were not deleted (e.g. if you had some header files open in Visual Studio, they would not be deleted). If you ever encounter this again, please let us know and we will re-investigate.
Regarding the debug issues, looks like your OpenOCD settings specify the target twice. Please try removing the second definition as shown below:
If stable debugging is the primary goal, we would recommend trying out CC3200 or other ARM-based chips. Espressif is doing a great job at offering superb functionality at a very low price, however they achieve this through not relying on the ARM core with a stable and reliable ecosystem of tools, but instead using a less popular Xtensa core and re-creating many tools from scratch. Given how popular their devices are, they will most likely polish all the rough edges relatively fast, however currently many of the ESP8266/ESP32-related tools are unstable.
We try to include workarounds for known issues and offer out-of-the-box setup and intuitive GUI, however resolving low-level communication issues between the 3rd-party tooling and the 3rd-party chip is unfortunately something beyond what we can offer as part of our products, sorry.
We’re at the start of development and I will discuss the possibility of the use of the CC3200 – thank you for the suggestion. I would much rather use an ARM core and expect further debug problems with the ESP32. However with my question I mostly meant, is there a better or more stable alternative to OpenOCD and/or the simple on-board JTAG adapter that you would recommend for use with VisualGDB (especially in consideration of the anticipated ESP32 problems)?
Hi,
For ARM devices the best supported JTAG/SWD debugger would be Segger J-Link. It costs more than low-end debuggers, but comes with its own low-level gdb stub that is actively maintained by Segger, tested with many devices and explicitly supported. Low-end debuggers like Olimex ARM-USB-OCD-H with OpenOCD are also quite reliable, although require some additional initial setup for some devices. Most of the issues you observed (like intermittent FLASH programming, random stops, inability to unwind frames, etc.) are specific for ESP8266/ESP32 simply because they have been figured out on ARM 10-20 years ago and Espressif didn’t have a chance to fix them yet.
Specifically for CC3200, debugging is reliable and works out-of-the-box, but programming the external FLASH memory is tricky and requires 3rd-party tools. For CC3220, OpenOCD has not been fully ported yet, so debugging it involves the proprietary TI XDS gdb stub, that is somewhat buggy, although we have customers successfully using it and can help you set it up if you decide to use it as well.
For ESP32 there is no 3rd-party tool ecosystem, so the Espressif OpenOCD port is the only way to debug their devices (ESP8266 also supports debugging over UART using a software gdb stub that runs on top of your software, but it has not been ported to ESP32 yet).
- You must be logged in to reply to this topic.