- This topic has 9 replies, 2 voices, and was last updated 2 years, 9 months ago by
.
-
Posts
-
Hi!
I have started to design a new project based on the esp32-s3.
Currently running:
GCC 8.4.0
GDB 8.1.0 r7 2021r2-patch 1
ESP-IDF V4.3.2In trying to use the official ESP32-S3-DevKitC-1, I am getting this error here: A fatal error occurred: This chip is ESP32-S3 not ESP32-S3(beta2). Wrong –chip argument?
From my basic research, the official S3 is only supported in v4.4 (https://github.com/espressif/arduino-esp32/issues/5594#issuecomment-996608334)My question is as follows: Is there currently a beta toolchain build that supports idf4.4 or is there an ETA on when a stable one will be available?
Thank you!
It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey
Thanks for renewing your support.
VisualGDB loads the ESP32 device list by reading the <sysgcc>\esp32\esp32-bsp\BSP.xml file (you can search for ESP32S3 for a quick example), and then simply passes it to ESP-IDF via the IDF_TARGET parameter.
Hence, if you would like to switch it from esp32s3 to esp32s3(beta2), you can simply patch the BSP.XML file and restart Visual Studio.
You can also try installing ESP-IDF 4.4 on top of our latest toolchain, although we have not finished fully testing this toolchain/ESP-IDF combination. We will run some tests on ESP-IDF 4.4 in the next few days, and will release an updated toolchain that will include it out-of-the-box.
Not really sure what is meant by the first part.
That BSP.xml file does not change between idf 4.3.2 and 4.4 but the command to program the esp does. The command goes from “–chip esp32s3-beta2” to “–chip esp32s3” when switching between idfs. Not really sure what determines that –chip parameter when trying to flash the esp.I went ahead and tried v4.4 and it seems to work on a hello world. What does not seem to work is the s3 built in USB-JTAG. After switching the driver over to libusb-WinUSB, attempting to conenct to the s3 over the usb jtag just results in this (repeated multiple times until a timeout):
Warn : Transport “jtag” was already selected
VisualGDB_OpenOCD_Ready
Info : Listening on port 6666 for tcl connections
Info : Listening on port 59091 for telnet connections
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : esp_usb_jtag: Device found. Base speed 40000KHz, div range 1 to 255
Info : clock speed 3076 kHz
Error: libusb_bulk_write error: LIBUSB_ERROR_NOT_FOUND
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
Error: esp_usb_jtag: device not found!
Error: esp_usb_jtag: failed to revive USB device!Hi,
First of all, we have released an updated ESP32 toolchain that includes ESP-IDF 4.4 (https://gnutoolchains.com/esp32/). Please note that it completely supersedes r7, as it includes both ESP-IDF 4.3.2 and 4.4, and the same versions of all other tools as the r7 toolchain.
Regarding the other issue, VisualGDB passes the chip type to ESP-IDF by specifying “-DIDF_TARGET=<…>” in CMake command line. The value of IDF_TARGET gets taken from BSP.XML. Hence, editing BSP.XML will allow changing the value of IDF_TARGET passed to ESP-IDF. If you would like to get it working with IDF 4.3.2, please consider dumping the commands used by VisualGDB as shown here, and adjusting it so that the build works. We can then help you configure VisualGDB to issue the adjusted command line.
The debug error looks like a bug in the OpenOCD or the device. Please try using the OpenOCD binaries from Espressif. If they work differently, we can investigate it further. If not, please consider reporting it as a bug to Espressif.
I still do not understand where that IDF_TARGET comes from as what is printed in the build log does not match what is in the XML file. Nowhere in the xml is the “esp32s3-beta2” string found. Comparing that XML between v4.3.2 and v4.4 there is no difference there.
Guess that does not matter much now that r8 is out with support for 4.4As far as the jtag thing, I just tried it with the official esp32 openocd binary (v0.11.0-esp32-20211220) under ubuntu 2.04 and it worked. I ended up playing around with available drivers and eventually found that WinUSB and libusb-win32 were not working but after trying with libusbK, it ended up finally working from initial inspection.
Thanks
Indeed, VisualGDB will set the IDF_TARGET to just esp32s3 per the XML file. You can verify it by dumping the CMake configuration command to a batch file and rechecking/tweaking it. We suggested editing BSP.XML because the ESP-IDF might have expected IDF_TARGET to be esp32s3(beta2).
Either way, it’s good to know it works with ESP-IDF 4.4. We will also keep an eye for feedback on the OpenOCD issues, and will consider switching the drivers installed by VisualGDB to libusbK.
Gotcha, thanks!
Final question, I am playing around with the Automatic Include Path Discovery feature. I see that it adds entries to cmakelists as relative paths. I’d like to change some of these to use an absolute path and I was wondering if there is some mechanism that propogates the visualgdb project variables over into cmake. For example, I’d like to path something in cmakelists by using $(ToolchainDir) variable. Is that possible currently?
Thanks
Sorry, auto-discovered paths within the toolchain directory is usually somewhat rare (ESP-IDF is indeed an exception), so the include path discovery doesn’t have any special logic for this case.
That said, since the settings are stored in CMakeLists.txt files, it’s extremely easy to adjust them by selecting the relevant block and doing a find-and-replace.
- You must be logged in to reply to this topic.