On registering my device and after hard resetting i’m getting this same error “Can’t find chipid” on both my ESP32DevC and my Sparkfun ESP32 thing. Any ideas how to fix this?
Today around 7pm cet time our servers were offline for a crash we recovered around 8pm. Did you get this error at that time?
If yes please try it again and let us know.
No, I’m getting it right now
it seems a driver issue; are you using Windows platform?
You can check if the drivers are correctly installed by clicking the ‘info’ icon on the right of the “Device Management Toolbar” with the device connected to your machine.
In the popup window, you should see in the list of device info the Port field and related serial port if it is recognized; if this value is ‘None’ something wrong happened during driver installation (or auto-installation for Win10).
Here you can find our doc for connecting Esp32 DevKitC and here the drivers.
Here, instead, the same for Sparkfun Esp32 Thing - here the drivers.
Let me know if this can help you
Its windows 10. the driver seem fine and it’s still having the same problem. I already have the SilLabs drivers installed.
I tried to uninstall it using your uninstaller and then reinstall it and it still remembered my previous project trys and settings which isn’t good. Is the chipid issue a server side problem or bad code on the IDE? Any other suggestions?
I was able to get the registration and virtualization working on my wemos D1 so thats good! Is it possible to sue your AWS example on a ESP8266 based system or do I need to run it on a ESP32? I noticed the example code is built around the ESP32.
the behavior of the ESP32 devices is very weird, the “can’t find chip-id” error does not depend on server side neither than IDE code.
During the registration phase, a very basic virtual machine is loaded in the microcontroller; this VM reads the internal chip id and cyclically writes it on the USB serial port.
So, to better understand and investigate this issue, you can try again to register one of your ESP32 devices (maybe you can post me the entire console log messages of this operation) and, even if the operation goes wrong, you can open the serial monitor (the last icon on the right of the “Device Management Toolbar”).
If the VM is correctly loaded, you should see the chip-id printed sequentially in your serial monitor; in this case, it could be a timing issue: for example, a timing mismatch between the Zerynth Studio waiting for chip-id in the serial port and the device that responses too late.
If in the serial port any char is printed, it could be a serial issue: for example an not proper usage of the serial port due to drivers (I know that you have installed more than once the right drivers but Windows often and for inexplicable reasons does not uninstall the old drivers or ignores the new ones).
One more check, you can open the cmd prompt and tap the following terminal commands (to be executed with the device connected to the pc):
ztc device discover --matchdb
This command checks the USB port of your machine and finds every Zerynth Supported Devices connected.<br>The result of this command should be like this (for the ESP32 DevKitC):<br><pre class="CodeBlock">name alias target uid chipid remote_id classname port disk ------------- --------------------------------------------------------- ------------- ---------------------------------------- -------- ----------- ------------ ------------ ------ ESP32 DevKitC zs:esp32_devkitc:e7a4bc050dddcfcc95a52881d92f1d4634052f87 esp32_devkitc e7a4bc050dddcfcc95a52881d92f1d4634052f87 Esp32DevKitC /dev/ttyUSB0Then you can tap this other command ("zs:es" are the first 5 chars of the alias field):This command registers the device from the command line; the result should be like this:ztc device register zs:es
```[info]> Starting device registration [info]> Burning bootloader... [info]> esptool.py v2.0 [info]> Connecting.... [info]> Chip is ESP32D0WDQ6 (revision 1) [info]> Uploading stub... [info]> Running stub... [info]> Stub running... [info]> Configuring flash size... [info]> Auto-detected Flash size: 4MB [info]> Compressed 11408 bytes to 7503... [info]> [info]> Writing at 0x00001000... (100 %) [info]> Wrote 11408 bytes (7503 compressed) at 0x00001000 in 0.7 seconds (effective 137.6 kbit/s)... [info]> Hash of data verified. [info]> Compressed 237840 bytes to 97665... [info]> [info]> Writing at 0x00010000... (16 %) [info]> Writing at 0x00014000... (33 %) [info]> Writing at 0x00018000... (50 %) [info]> Writing at 0x0001c000... (66 %) [info]> Writing at 0x00020000... (83 %) [info]> Writing at 0x00024000... (100 %) [info]> Wrote 237840 bytes (97665 compressed) at 0x00010000 in 8.6 seconds (effective 221.1 kbit/s)... [info]> Hash of data verified. [info]> Compressed 3072 bytes to 156... [info]> [info]> Writing at 0x00008000... (100 %) [info]> Wrote 3072 bytes (156 compressed) at 0x00008000 in 0.0 seconds (effective 1393.6 kbit/s)... [info]> Hash of data verified. [info]> Compressed 1024 bytes to 20... [info]> [info]> Writing at 0x00390000... (100 %) [info]> Wrote 1024 bytes (20 compressed) at 0x00390000 in 0.0 seconds (effective 1469.4 kbit/s)... [info]> Hash of data verified. [info]> [info]> Leaving... [info]> Hard resetting... [info]> Found chipid: XXXXXXXXXXXXXX [info]> Device ESP32 DevKitC registered with uid: YYYYYYYYYYYYYYYYYY
``` Can you post me the result of this commands?
Regarding the Installation, Zerynth ecosystem needs 2 folders:
- the installer folder under C:\\Program Files\\Zerynth
- the software folder under C:\\Users\\username\\zerynth2
To remove completely Zerynth from a machine you can use the unistaller to remove the installer part and you can delete the zerynth2 folder to remove the software part.
If you remove only the installer some settings are still stored in the zerynth2 folders and they will recur on new installations.
Regarding the projects, a Zerynth Project is nothing else that a folder containing the project files and an hidden file (.zproject) where a json dict with project info are stored to be recognized automatically by the Zerynth Studio.
You can move them, drug and drop files, etc. as any others folders/files in the machine (usually Zerynth Studio searches by default if there are Zerynth projects in your home directory).
Regarding the execution of the AWS example on an ESP8266 based board, unfortunately, it is not possible because SSL sockets are not so stable and are not supported on ESP8266.
Please let me know if some of my advice has been helpful for you :)
Otherwise, if you agree, we can open a TeamViewer section where I will try remotely to solve your problem
Thanks for helping out. Would love to get this working. I’m getting the same issues from the command line as from the IDE following your directions. Ive tried it both with the ESP32devC and Sparkfun Thing32.
I fixed the problem. It wasn’t a baud rate, driver, or COM port issue. I suspected what the issue was when I realized the WeMos D1 was brand new, unused, and the Sparkfun Thing32 and ESP32Devc had previously been used in Arduino and I had old code on the board. So how I fixed the problem is using the
Espressf flash tool at http://espressif.com/en/support/download/other-tools
from there I uploaded the target_1.bin but in essence I erased the old code and/or re-flashed the chip. From there I was able to get a ChipID when registering and then I could visualize. So what I think is happening is your tool is writing its frimware and VM but its not erasing the entire chip first. So when it now looks for the ChipID there is either old junk in memory or something else that makes it so your tool cant find the ChipID. I suggest you have your tool completely erase any old firmware before it looks for the ChipID. when it utilizes the esptool.py it seems to be failing to reformat everything as needed. You should easily be able to test this by loading some other program via Arduino or the espressif-sdk then seeing if the problem reoccurs compared to a brand new, unprogrammed or factory programmed ESP chip.
very glad to hear that (sorry for the late answer) :#
This is a very helpful advice for us; we will investigate this behavior in combination with the programming made by other tools and we will update our registration and virtualization phases for ESP32 devices to fix it.
Indeed, we start to write binary files through the esptool from 0x1000 address as recommended on the esptool documentation, and we never notice this kind of bad functioning.
So many thanks for helping us in this analysis; it will be shared in our community and soon in one of our future patches we will release an update for it.
Happy coding (now with your ESP32 devices)
Thanks man, for saving my time.