Cant Flash - cant find ttyACM0?

[robotica72]

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?

[kristiankielhofner]

Which distro is this?

Can you run:

ls -l /dev/ttyACM0
id

and provide the output?

[robotica72]

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]

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??

[kristiankielhofner]

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

FLASH_BAUD=115200

and run erase-flash and flash again.

[robotica72]

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

[kristiankielhofner]

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

[stintel]

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.

[robotica72]

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]

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

[hamishcunningham]

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

[kristiankielhofner]

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.

[robotica72]

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.

[kristiankielhofner]

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."

[robotica72]

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.

[SamJongenelen]

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

[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!

[robotica72]

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.

[kristiankielhofner]

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]

@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.

[hamishcunningham]

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 :(

[kristiankielhofner]

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.

[robotica72]

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...

[kristiankielhofner]

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...

[robotica72]

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

[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?

[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!

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 :)

[kristiankielhofner]

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]

@robotica72 #70

[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?

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.

[ssurovich]

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

[SamJongenelen]

It's young but men is it everything I hoped for...! I do have some issues of course, will report / ask later

[ssurovich]

Its speedy, no doubt - instant for basic HA intents. Im already thinking about how I can, finally, move on to having my HA be Jarvis - The voice part is pretty easy now with Willow - Now I need to figure out how to add feedback to my Google Home speakers when Willow executes something. Ive re-created Jarvis' voice using services out there, but they are all API driven rather than local, so that will add delay to the replies (and a cost ... Im okay with a cost add-on if it works quick).

And of course, Ill need a new wakeup word... Jarvis :)

[kristiankielhofner]

Thanks! Depending on which rev you have we've improved response times by about 30% in the last 24 hours or so.

We also introduced a new user-configurable VAD timeout (that depending on your rate of speech and configured value) is truly "did that really just happen?" fast. I like 100 ms.

Are you using local or server based speech rec? I only ask because the Willow Inference Server (open source release next week) and current default in the config (our best-effort community hosted server) can transcribe anything and you should be able to do everything you're describing with that.

We have audio output and TTS (WIS already provides TTS) on the roadmap for Willow.

[ssurovich]

Local for now - Just wanted to get the flash working and test it out at a high level - Hard to believe it an be improved actually! (Its that good)

I was looking into the Inference Serer and that will be the way to go - I have no issues putting some GTX/RTX card in one of my servers just for that to make sure its quick - Im assuming it will be more about the RAM, so I wont need an RTX 4090 or anything crazy?

[kristiankielhofner]

We've spent months highly optimizing the Willow Inference Server. Lowest support card is the GTX 1060 3GB to load base, medium, and large simultaneously and with the default model and settings we have on the community hosted server (Whisper medium > 40 languages, beam 1) it can transcribe 3.8 seconds of speech in 588ms on a GTX 1060. That's fairly long for a voice command but gives a general idea. Here are some other benchmarks:

Device	Model	Beam Size	Speech Duration (ms)	Inference Time (ms)	Realtime Multiple
RTX 4090	large-v2	5	3840	140	27x
H100	large-v2	5	3840	294	12x
H100	large-v2	5	10688	519	20x
H100	large-v2	5	29248	1223	23x
GTX 1060	large-v2	5	3840	1114	3x
Tesla P4	large-v2	5	3840	1099	3x
RTX 4090	medium	1	3840	84	45x
GTX 1060	medium	1	3840	588	6x
Tesla P4	medium	1	3840	586	6x
RTX 4090	medium	1	29248	377	77x
GTX 1060	medium	1	29248	1612	18x
Tesla P4	medium	1	29248	1730	16x
RTX 4090	base	1	180000	277	648x (not a typo)

I think it's clear we have a different approach to a locally hosted private voice assistant than the rest of the open source ecosystem and buying NVIDIA hardware may be off-putting for some users but I'm going to write up our approach, the thinking behind it, and of course the tangible results.

Long story short the approach up to this point has been to spend ~$120 (at retail prices) per Raspberry Pi as a voice assistant. I don't want to speak ill of projects but the results aren't going to threaten Alexa anytime soon and while we might not have a problem with a jumbled mess of wires, assembly, and managing what is a full Linux computer X number of assistants isn't compelling for most people.

With Willow it's $50 per assistant that can do local recognition. Or if you want Jarvis and are starting from zero you can buy a GPU off eBay (I think GTX 1070 is the sweet spot right now) for $120 and put it in an existing desktop or get something like a Dell Precision off eBay for $200 (I just ordered this exact configuration to demo and document it). So for us, the math breaks down like so:

Four Raspberry Pis = $480 (MSRP pricing, in reality much more than that) Something to run Home Assistant = another $120 (let's say Raspberry Pi again) Total = $600

VS

Four Willows = $200 Machine of your choice from eBay = $200 GTX 1070 = $120 Total = $520

...and meanwhile this machine (with CUDA GPU with spare memory and compute) is going to absolutely crush a Raspberry Pi for Home Assistant and anything else tinkerers like us enjoy experimenting with.

[kristiankielhofner]

Sorry, too excited to have mentioned this - if we want to move the GPU, etc discussions to GH discussions that would be better as eventually we'll close this issue and it will effectively disappear.

[rogerquake]

I ran into a failure flashing from my Linux host which I used to build the image using Docker. So I began to use the method of copying the willow-dist.bin file so I could try and flash on Windows. I was able to erase the device using the ESPWebTool and then flashed it with the bin. However after the device boots up, it's stuck on a screen that says:

Welcome to Willow Starting up (server)

Any ideas where I could have messed up?

[ssurovich]

I ran into a failure flashing from my Linux host which I used to build the image using Docker. So I began to use the method of copying the willow-dist.bin file so I could try and flash on Windows. I was able to erase the device using the ESPWebTool and then flashed it with the bin. However after the device boots up, it's stuck on a screen that says:

Welcome to Willow Starting up (server)

Any ideas where I could have messed up?

Strange - I didnt have any luck with the Webtool completing, so I used esptools on Windows in Python and it worked great. Im wondering if that would fix your issue (No idea why, but since it worked well for me... who knows).

[rogerquake]

Figured it out! The config tool was appending data to items I was configuring such as my Wifi SSID and HomeAssistant URL. When I edited the sdkconfig file manually with pico in the container and re-built, it all worked fine!

[sparkydave1981]

I tried to flash my first ESPbox last night and had trouble regarding the USB port as well. I'll have to come back here with the actual error message but it was along the lines of not having access to the port. I am running in a Terminal window in Ubuntu. I had to use sudo for a lot of commands through the process as I was logged in as a normal? user. (My Linux experience is limited)

When I executed the export PORT=/dev/ttyACM0 command, nothing displayed, it just seemed to accept the command and did a line return. Is that expected?

When I entered the ./utils.sh erase-flash command I got a PORT error.

[kristiankielhofner]

Hah yes, this is the issue that will never die ;).

Yes, the export isn't supposed to return anything. General long-standing Unix/Linux convention is to not output anything when a command is successful.

Almost all of these issues come down to permissions. Linux doesn't let regular users write to ports by default so you (usually) either need to be in the dialout group or use sudo with the serial port access commands. utils.sh checks for these things now and will try to (hopefully helpfully) tell you where things are going wrong.

[sparkydave1981]

use sudo with the serial port access commands.

I did use sudo but still had trouble. I'll copy / paste the actual error tonight when I get home from work.

[sparkydave1981]

This is from the bottom part of the dmesg command down to where I tried to do the erase-flash.

[88005.461263] usb 1-1: New USB device found, idVendor=303a, idProduct=1001, bcdDevice= 1.01
[88005.461286] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[88005.461294] usb 1-1: Product: USB JTAG/serial debug unit
[88005.461300] usb 1-1: Manufacturer: Espressif
[88005.461306] usb 1-1: SerialNumber: 7C:DF:A1:FF:41:94
[88005.491319] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
[88005.491360] usbcore: registered new interface driver cdc_acm
[88005.491362] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
x@x-NUC7PJYH:~/willow$ export PORT=/dev/ttyACM0
x@x-NUC7PJYH:~/willow$ ./utils.sh erase-flash
You don't have permission to write to /dev/ttyACM0 - exiting
You need to either run this command with sudo or add yourself to the dialout group
x@x-NUC7PJYH:~/willow$ sudo ./utils.sh erase-flash
You need to define the PORT environment variable to do serial stuff - exiting
x@x-NUC7PJYH:~/willow$ sudo export PORT=/dev/ttyACM0
sudo: export: command not found
x@x-NUC7PJYH:~/willow$ export PORT=/dev/ttyACM0
x@x-NUC7PJYH:~/willow$ sudo ./utils.sh erase-flash
You need to define the PORT environment variable to do serial stuff - exiting
x@x-NUC7PJYH:~/willow$ 

I'm not sure what is wrong...

[kristiankielhofner]

I have updated the help text for these issues. Please run git pull in your willow directory and read the error messages from these various commands.

Let us know if it is helpful and leads to success or if you have any other additional issues or feedback!

[sparkydave1981]

Perfect! That's for the new tips. I got it flashed. Now to get it connected to Home Assistant :-)

EDIT: ok, this is crazy. I didn't have to do anything since that was done with the token setup. It just works!!!

[skrilla0]

I was in the process of re-flashing my S3 with the latest updates, and now having the error of finding the USB device. I am also flashing via a VM with USB passthrough, but was fine the first time around, and also just flashed a different S3, just fine.

I've tried resetting the environment ./utils.sh destroy and re-building but still no luck. The output from dmesg shows the following error, but not sure how to de-bug

[286570.045746] cdc_acm 2-1:1.0: ttyACM0: USB ACM device
[286573.387236] usb 2-1: USB disconnect, device number 82
[286575.892954] usb 2-1: new full-speed USB device number 83 using xhci_hcd
[286581.480928] usb 2-1: device descriptor read/all, error -110
[286581.816829] usb 2-1: new full-speed USB device number 84 using xhci_hcd
[286582.272759] xhci_hcd 0000:02:1b.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
[286587.368799] usb 2-1: device descriptor read/all, error -110
[286587.369550] usb usb2-port1: attempt power cycle
[286588.020713] usb 2-1: new full-speed USB device number 85 using xhci_hcd
[286593.512687] usb 2-1: device descriptor read/8, error -110
[286598.888572] usb 2-1: device descriptor read/8, error -110

[stintel]

I ran into a bunch of USB disconnect issues myself yesterday, on Linux on bare metal. Try another cable and/or reduce FLASH_BAUD in utils.sh.

[ssurovich]

I had nothing but issues with passthrough (and Ive been around VMware since Workstation 1 and ESX 1.7) - Thats why I gave up and went to native Windows to flash, and that work right away. I flashed about 20 times to test the workflow and it did fail once with a timeout, but it worked right after that.

Have you tried to enter download mode on the ESP before flashing? That does see to help a lot when you have timeouts.

[skrilla0]

I'm at a point where it's no longer detecting the USB device when even trying to erase the flash, tried a couple cables, but no luck. dmesg will show the device listed, but ls -l /dev/ttyACM0 won't find it.

[hamishcunningham]

ls /dev/ttyACM* too?

On Fri, 16 Jun 2023, 16:46 skrilla0, @.***> wrote:

I'm at a point where it's no longer detecting the USB device when even trying to erase the flash, tried a couple cables, but no luck. dmesg will show the device listed, but ls -l /dev/ttyACM0 won't find it.

— Reply to this email directly, view it on GitHub https://github.com/toverainc/willow/issues/60#issuecomment-1594895099, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBRBFFJ4NRLJMZJM6G65PDXLR5VFANCNFSM6AAAAAAYHCOWQ4 . You are receiving this because you were mentioned.Message ID: @.***>