Forum Replies Created
-
Posts
-
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)?
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?
- 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?
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.
