willow icon indicating copy to clipboard operation
willow copied to clipboard

Cant Flash - cant find ttyACM0?

Open robotica72 opened this issue 1 year ago • 39 comments

Everything seems to go well, up to erasing the flash - It cant find the port, but dmesg shows the Espressif and that it is on /dev/ttyACM0. Looking at /dev - I can see ttyACM0 is there. If I disconnect the USB cable, ttyACM0 does go away...

Using venv for esptool esptool.py v4.5.1 Serial port /dev/ttyACM0

A fatal error occurred: Could not open /dev/ttyACM0, the port doesn't exist

dmesg when plugged in:

[ 3364.126378] usb 2-2.1: new full-speed USB device number 8 using uhci_hcd [ 3364.434428] usb 2-2.1: New USB device found, idVendor=303a, idProduct=1001, bcdDevice= 1.01 [ 3364.434435] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 3364.434437] usb 2-2.1: Product: USB JTAG/serial debug unit [ 3364.434439] usb 2-2.1: Manufacturer: Espressif [ 3364.434440] usb 2-2.1: SerialNumber: 7C:DF:A1:E8:22:F8 [ 3364.438405] cdc_acm 2-2.1:1.0: ttyACM0: USB ACM device [ 3408.337353] usb 2-2.2: USB disconnect, device number 7 [ 3412.010379] usb 2-2.1: USB disconnect, device number 8 [ 3412.923174] usb 2-2.1: new full-speed USB device number 9 using uhci_hcd

Only potential issue - this is a VM, but Im passing the USB through, and I never had issues in the past doing this on any flashing (ESP / etc...)

Any ideas?

robotica72 avatar May 18 '23 23:05 robotica72

Which distro is this?

Can you run:

ls -l /dev/ttyACM0
id

and provide the output?

kristiankielhofner avatar May 18 '23 23:05 kristiankielhofner

Damn - Was just going to send it and noticed I was running it as my standard user - ran utils.sh in a root shell and its working.

Sorry for the rookie mistake! and thanks for the quick reply.

robotica72 avatar May 18 '23 23:05 robotica72

Different issue on the flash now:

Using venv for esptool esptool esp32s3 -p /dev/ttyACM0 -b 2000000 --before default_reset --after hard_reset write_flash --flash_mode dio --flash_freq 80m --flash_size 16MB 0x0 bootloader/bootloader.bin 0x10000 willow.bin 0x8000 partition_table/partition-table.bin 0x210000 srmodels/srmodels.bin 0x710000 audio.bin esptool.py v4.5.1 Serial port /dev/ttyACM0 Connecting... Chip is ESP32-S3 (revision v0.1) Features: WiFi, BLE Crystal is 40MHz MAC: 7c:df:a1:e8:22:f8 Uploading stub... Running stub... Stub running... Changing baud rate to 2000000 Changed. Configuring flash size... Flash will be erased from 0x00000000 to 0x00005fff... Flash will be erased from 0x00010000 to 0x00191fff... Flash will be erased from 0x00008000 to 0x00008fff... Flash will be erased from 0x00210000 to 0x005f3fff... Flash will be erased from 0x00710000 to 0x0078ffff... Compressed 22256 bytes to 13957... Wrote 22256 bytes (13957 compressed) at 0x00000000 in 0.4 seconds (effective 454.7 kbit/s)...

A fatal error occurred: Packet content transfer stopped (received 24 bytes)

Ideas??

robotica72 avatar May 18 '23 23:05 robotica72

Try creating a .env file in the willow directory with:

FLASH_BAUD=115200

and run erase-flash and flash again.

kristiankielhofner avatar May 18 '23 23:05 kristiankielhofner

No luck ... same issue

Using configuration overrides from .env file Using venv for esptool esptool esp32s3 -p /dev/ttyACM0 -b 115200 --before default_reset --after hard_reset write_flash --flash_mode dio --flash_freq 80m --flash_size 16MB 0x0 bootloader/bootloader.bin 0x10000 willow.bin 0x8000 partition_table/partition-table.bin 0x210000 srmodels/srmodels.bin 0x710000 audio.bin esptool.py v4.5.1 Serial port /dev/ttyACM0 Connecting.... Chip is ESP32-S3 (revision v0.1) Features: WiFi, BLE Crystal is 40MHz MAC: 7c:df:a1:e8:22:f8 Uploading stub... Running stub... Stub running... Configuring flash size... Flash will be erased from 0x00000000 to 0x00005fff... Flash will be erased from 0x00010000 to 0x00191fff... Flash will be erased from 0x00008000 to 0x00008fff... Flash will be erased from 0x00210000 to 0x005f3fff... Flash will be erased from 0x00710000 to 0x0078ffff... Compressed 22256 bytes to 13957... Wrote 22256 bytes (13957 compressed) at 0x00000000 in 0.4 seconds (effective 455.3 kbit/s)...

A fatal error occurred: Packet content transfer stopped (received 24 bytes)

The erase was fine - of course that means the unit has nothing on the LCD now :) But it just wont flash

robotica72 avatar May 18 '23 23:05 robotica72

We haven't done any testing with USB passthrough or VMs... Here's a workaround for you (for now):

./utils.sh dist

Disable USB passthrough to the VM. Copy willow-dist.bin to your host machine. Unplug and plug-in your ESP BOX just to be sure.

Then head over to the ESP web flashing tool (Chrome is best if you have it)

Provide access to the port when prompted Click the red "Erase flash" Set flash address to 0x0 Click chose file, find willow-dist.bin wherever you put it on your host. Click Program

kristiankielhofner avatar May 19 '23 00:05 kristiankielhofner

I suspect the USB device disconnects during flash. In another terminal, run journalctl -f -k to confirm that. If that's the case, you might be able to work around that by enabling download mode: press the BOOT/CONFIG button (top button on the left side) while powering up the device. Try flashing again after that.

If that doesn't work, you'll have to use the web flashing tool.

stintel avatar May 19 '23 00:05 stintel

Strange - I program a lot of ESP chips with the same laptop and cable. Im having no luck here - Tried the web tool, crashes at 2% - Erased again, enabled download mode, and same thing stops at 1 or 2%

esptool.js Serial port WebSerial VendorID 0x303a ProductID 0x1001 Connecting.... Detecting chip type... ESP32-S3 Chip is ESP32-S3 Features: Wi-Fi,BLE Crystal is 40MHz MAC: 7c:df:a1:e8:22:f8 Uploading stub... Running stub... Stub running... Changing baudrate to 921600 Changed Erasing flash (this may take a while)... Chip erase completed successfully in 1.443s Compressed 7929856 bytes to 4295190... Writing at 0x1000... (0%) Writing at 0x1216f... (0%) Writing at 0x1d225... (1%) Writing at 0x287b3... (1%) Error: Timeout

robotica72 avatar May 19 '23 00:05 robotica72

Im going to try a new cable - another attempt got to 4%

Writing at 0x0... (0%) Writing at 0x1116f... (0%) Writing at 0x1c225... (1%) Writing at 0x277b3... (1%) Writing at 0x2c265... (1%) Writing at 0x3380e... (2%) Writing at 0x3f3ea... (2%) Writing at 0x4ab20... (3%) Writing at 0x55fd0... (3%) Writing at 0x5db1e... (3%) Writing at 0x635f5... (4%) Error: Timeout

robotica72 avatar May 19 '23 00:05 robotica72

I've seen this on S3 chips a bit, and recommend the boot/reset combination if you haven't tried it already

hamishcunningham avatar May 19 '23 07:05 hamishcunningham

That's really good information! Flashing S3 has always been really reliable to me and I've never had to use the boot/reset trick but I'll add it to the README.

kristiankielhofner avatar May 19 '23 11:05 kristiankielhofner

Yeah, still no luck - Ive tried the Windows Flasher, web, and of course the utils.sh flasher - the highest a flash has managed to get to is 5% before it fails. Its usually 2-3% before it fails.

Ive tried 2 machines and countless different cables - and since its been erased, I only have a brick now with a black screen. Bought from Adafruit and since it was erased and a flash was attempted, Im guessing they wouldnt accept a return on it.

robotica72 avatar May 19 '23 11:05 robotica72

Have you tried the boot/reset button combination as suggested by @stintel and @hamishcunningham :

"I suspect the USB device disconnects during flash. In another terminal, run journalctl -f -k to confirm that. If that's the case, you might be able to work around that by enabling download mode: press the BOOT/CONFIG button (top button on the left side) while powering up the device. Try flashing again after that."

kristiankielhofner avatar May 19 '23 11:05 kristiankielhofner

I did - Ive tried programming using download mode and standard - Actually, without download mode the device will just loop now between connected and disconnected - If I enter download mode, it at least stays connected.

robotica72 avatar May 19 '23 12:05 robotica72

I had the same issue. Only using esptools from CLI worked, all other flashers didn't (multiple web, the Chinese one)

In my case, it is because I didn't erase_flash before first time Willow flash (it's in the manual....). Your device is indeed boot looping

The device is recoverable, you can flash the demo bin on 0x0 and then erase_flash.

Edit: i used win11 wsl2 with USBIPD and Ubuntu. Man what a hassle to get it working

SamJongenelen avatar May 19 '23 12:05 SamJongenelen

@SamJongenelen - erase-flash is THE critical step first step. I thought this was clear in the documentation but we keep encountering this. I'm going to create a one-shot install script for first time users to go through the required steps.

Willow is not even two months old and other than a handful of very technical developers on the team Monday (four days ago) was the first time the rest of the world has attempted these steps. The good news is you're a VERY early adopter. The bad news is there are some rough edges as we learn how users interpret our documentation and encounter other issues.

The current state of installation includes build from source because Willow is advancing VERY rapidly. Just over the past few days we've fixed multiple crashes, dramatically improved device performance, and cut latency on wake and speech recognition down by 30%. In the first few days.

Of course (within the next month or so) we will have ready-built firmware images users can easily configure after flash but until the ESP BOX (or our own version) ships with Willow flashing of some sort will be a requirement and that's the step users seem to get hung up on the most (as this issue reflects).

I'm learning more and more that I'm really bad and documentation and probably shouldn't attempt it. We'd certainly appreciate more feedback, PRs, and maybe even an official documentation manager!

kristiankielhofner avatar May 19 '23 12:05 kristiankielhofner

I pretty much always erase a chip before programming - so I did do that step first (and would have, even without the docs mentioning it). Ive tried the demo flash too ad its failing at 2% - Im going to try yet another laptop, never know, maybe the third machine is the charm :)

Never had an issue like this, I use ESP32s in a lot of devices I create - I have at least 20 on my network for various functions and flashing / erasing / etc... has never been an issue.

robotica72 avatar May 19 '23 12:05 robotica72

What's interesting about this issue is I would have expected the build steps would be the most problematic yet here we are.

The ESP BOX is manufactured by Espressif. We don't have anything to do with the hardware other than building software for it. After build, we use bog-standard esptool.py from Esspressif to flash a device that is 100% built and sold by Espressif. One perspective could be we have nothing to do with the flashing failures discussed in this issue.

However, I take ownership of issues users experience even it they're not technically our fault. We will work through this one way or another.

@SamJongenelen - Can you share the version of esptool.py you used successfully and the command line arguments?

kristiankielhofner avatar May 19 '23 13:05 kristiankielhofner

@robotica72 "Never had an issue like this, I use ESP32s in a lot of devices I create"

The ESP BOX uses the ESP32 S3 which is more-or-less the latest and greatest from Espressif. I suspect a lot of these issues are due to that. It's an "ESP32" but different enough to also kind of not be one at the same time.

kristiankielhofner avatar May 19 '23 13:05 kristiankielhofner

A big difference is that the S3 has internal USB support, which means that most dev boards connect USB directly to the chip instead of to a separate UART translator like CP2104. This makes it harder to flash in my experience.

I've seen errors with older esptool versions that went away with later versions but I can't remember the exact numbers :(

hamishcunningham avatar May 19 '23 14:05 hamishcunningham

Wow, thanks for letting me know! I missed that somehow and yes that's definitely a BIG difference vs ESP32.

By default we're installing the latest esptool.py 4.5.1 in the venv on the host for flashing. It can be overriden in the .env file so might be worth asking users to try different versions for now in case there's a regression or something in the latest-latest.

kristiankielhofner avatar May 19 '23 14:05 kristiankielhofner

I just had success - I had to use the Python esptools in Windows to flash the firmware and it went through without any issues!

Maybe it will help others that have issues

Adding the command view and output for context:

PS C:\Python27> esptool.py --port COM8 write_flash 0x0 .\willow-dist.bin esptool.py v3.3.3 Serial port COM8 Connecting... Detecting chip type... ESP32-S3 Chip is ESP32-S3 (revision v0.1) Features: WiFi, BLE Crystal is 40MHz MAC: 7c:df:a1:e8:22:f8 Uploading stub... Running stub... Stub running... Configuring flash size... Flash will be erased from 0x00000000 to 0x0078ffff... Compressed 7929856 bytes to 4295190... Wrote 7929856 bytes (4295190 compressed) at 0x00000000 in 77.2 seconds (effective 822.1 kbit/s)... Hash of data verified.

Leaving... Hard resetting via RTS pin...

robotica72 avatar May 19 '23 14:05 robotica72

Great! Let us know how things go!

None of the devs use Windows personally and I thought we might want to add something to use python esptools natively in Windows for Windows users. I'll just have to dig up something running Windows and work on it...

kristiankielhofner avatar May 19 '23 14:05 kristiankielhofner

Yeah, I use Linux a lot but only in VMs - I do 3D work too much and need my Windows tools for Photogrammetry, 3D Scanning, etc...

If I can offer anything to help on the Windows side to save you time, let me know

robotica72 avatar May 19 '23 14:05 robotica72

We'd really appreciate the help with Windows!

From what I remember we'll probably have to have users install Python from the official Windows installer and write a Powershell script? Does that make sense?

kristiankielhofner avatar May 19 '23 14:05 kristiankielhofner

@SamJongenelen - erase-flash is THE critical step first step. I thought this was clear in the documentation but we keep encountering this. I'm going to create a one-shot install script for first time users to go through the required steps.

Willow is not even two months old and other than a handful of very technical developers on the team Monday (four days ago) was the first time the rest of the world has attempted these steps. The good news is you're a VERY early adopter. The bad news is there are some rough edges as we learn how users interpret our documentation and encounter other issues.

The current state of installation includes build from source because Willow is advancing VERY rapidly. Just over the past few days we've fixed multiple crashes, dramatically improved device performance, and cut latency on wake and speech recognition down by 30%. In the first few days.

Of course (within the next month or so) we will have ready-built firmware images users can easily configure after flash but until the ESP BOX (or our own version) ships with Willow flashing of some sort will be a requirement and that's the step users seem to get hung up on the most (as this issue reflects).

I'm learning more and more that I'm really bad and documentation and probably shouldn't attempt it. We'd certainly appreciate more feedback, PRs, and maybe even an official documentation manager!

Yeah I know, I know. I didn't start with flashing Willow immediately and didn't read it there. No harm i learned a lot about flashing esp32 and python venv :)

SamJongenelen avatar May 19 '23 15:05 SamJongenelen

No worries! I don't mean to sound preachy but even though it might not look like it on the surface and with demo videos, etc Willow is still VERY young and I want to make sure people understand that.

kristiankielhofner avatar May 19 '23 15:05 kristiankielhofner

@robotica72 #70

kristiankielhofner avatar May 19 '23 15:05 kristiankielhofner

We'd really appreciate the help with Windows!

From what I remember we'll probably have to have users install Python from the official Windows installer and write a Powershell script? Does that make sense?

Makes sense - My Python27 is just a plain old install, so could use any deployment I think. Just needs Python, pip and then pip install for the esptools (and of course the firmware). The steps are pretty easy, assuming you have the FW file.

Ill joing this conversation from my "normal" GIT account, I use this one for only a few things and didnt mean to use it when I posted.

robotica72 avatar May 19 '23 16:05 robotica72

** Not that it matters too much, but this is my standard account - so I wont be posting from the other one **

ssurovich avatar May 19 '23 17:05 ssurovich