search

esphome / issues

Issue Tracker for ESPHome
https://esphome.io/
290 stars 36 forks source link

Pi Pico W not rebooting after esphome update to 2023.3.0 #4308

Closed freddiemare closed 1 year ago

freddiemare commented 1 year ago

The problem

I only updated my pi pico w devices and they all stopped rebooting after updating esphome to 2023.3.0 I have one device still working and am busy trying to see the difference in breaking changes that were implemented any guide to what to look out for will be greatly helpful since I have no idea wah to look for besides the break-in change implementations.

Which version of ESPHome has the issue?

2023.3.0

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2023.3.0

What platform are you using?

RP2040

Board

pi pico w

Component causing the issue

dont know what component since no reboot

Example YAML snippet

esphome:
  name: plot35gate
  project:
    name: "plot35.gate"
    version: "1.0.2"

  on_boot:
    priority: -100.0 
    then:
       - switch.turn_on: gate_board_LED_switch
       - switch.turn_on: gate_light

rp2040:
  board: rpipicow
  framework:
    # Required until https://github.com/platformio/platform-raspberrypi/pull/36 is merged
    platform_version: https://github.com/maxgerhardt/platform-raspberrypi.git

# Enable logging
logger:
 # level: DEBUG

# Enable Home Assistant API
api:
#  encryption:
#    key: !secret api_Gate_key
  reboot_timeout: 60sec 

ota:
  password: !secret ota_Gate_password

wifi:
  reboot_timeout: 30s
  output_power: 20db
  power_save_mode: none
  networks:
    - ssid: !secret wifi_ssid2
      password: !secret wifi_password2
      #fast_comnect: true
      bssid: 56:AF:97:A3:47:EE
      manual_ip:
        # Set this to the IP of the ESP
        static_ip: 192.168.2.131
        # Set this to the IP address of the router. Often ends with .1
        gateway: 192.168.2.1
        #The subnet of the network. 255.255.255.0 works for most home networks.
        subnet: 255.255.255.0
        dns1: 1.1.1.1
        dns2: 192.168.2.1

    - ssid: !secret wifi_ssid2
      password: !secret wifi_password2
      #fast_connect: true
      bssid: F4:E5:F2:AC:52:9F
      hidden: True
      manual_ip:
        # Set this to the IP of the ESP
        static_ip: 192.168.2.131
        # Set this to the IP address of the router. Often ends with .1
        gateway: 192.168.2.1
        #The subnet of the network. 255.255.255.0 works for most home networks.
        subnet: 255.255.255.0
        dns1: 1.1.1.1
        dns2: 192.168.2.1
  ap:
    ssid: "Plot35Gate"
    password: "123456"

output:
  # Built-in LED
  - platform: gpio
    pin:
      number: 32 
      mode: output
    id: gate_board_LED

    # Relay 1 Outputs
  - platform: gpio
    pin: 
      number: 12  
      mode: output
    id: gpio_12
    inverted: true

    # Relay 2 Outputs
  - platform: gpio
    pin: 
      number: 13 
      mode: output
    id: gpio_13
    inverted: true

    # Relay 3 Outputs
  - platform: gpio
    pin: 
      number: 14 
      mode: output
    id: gpio_14
    inverted: true

    # Relay 4 Outputs Gate Lights
  - platform: gpio
    pin: 
      number: 15 
      mode: output
    id: gpio_15
    inverted: true

switch:
  - platform: output
    id: gate_board_LED_switch
    output: gate_board_LED
    name: "Gate Board LED"

  - platform: restart
    id: gate_restart
    name: "Gate Restart"

  - platform: output
    id: gate_light
    output: gpio_15
    name: Gate Light

  - platform: gpio
    pin: 12
    id: gate_open_trigger
    name: "Gate Open"
    icon: "mdi:gate"
    inverted: true
    on_turn_on:
    - delay: 500ms
    - switch.turn_off: gate_open_trigger

  - platform: gpio
    pin: 13
    id: pedestrian_gate_open_trigger
    name: "Gate Open Pedestrian"
    icon: "mdi:gate"
    inverted: true
    on_turn_on:
    - delay: 500ms
    - switch.turn_off: pedestrian_gate_open_trigger

binary_sensor:
  - platform: status
    name: "Gate Connection Status"
    id: gate_connection_status

  - platform: gpio
    id: gate_bell
    pin:
      number: 7
      inverted: true
      mode:
        input: true
        pullup: true
    icon:  "mdi:bell"
    name: "Gate Bell"

  - platform: gpio
    id: gate_IRBC_alarm
    pin:
      number: 8
      inverted: true
      mode:
        input: true
        pullup: true
    icon:  "mdi:gate-alert"
    name: "IRBC Alarm"

  - platform: gpio
    id: gate_status
    pin:
      number: 9
      inverted: true
      mode:
        input: true
        pullup: true
    icon:  "mdi:gate"
    name: "Gate Status"

  - platform: gpio
    id: tamper_alarm
    pin:
      number: 10
      inverted: false
      mode:
        input: true
        pullup: true
    icon:  "mdi:alarm-light"
    name: "Tamper Alarm"

  - platform: gpio
    id: gate_pir_movement
    pin:
      number: 11
      inverted: true
      mode:
        input: true
        pullup: true
    icon:  "mdi:motion-sensor"
    name: "Gate PIR Movement"
    device_class: motion

text_sensor:
  - platform: wifi_info
    ip_address:
      name: Gate IP Address
    ssid:
      name: Gate Connected SSID
    bssid:
      name: Gate Connected BSSID
    mac_address:
      name: Gate Mac Wifi Address
    scan_results:
      name: Gate Latest Scan Results

sensor:      
  - platform: duty_cycle
    update_interval: 1s
    pin: 
      number: 9
      inverted: yes
      #mode: INPUT_PULLUP
      mode:
        input: true
        pulldown: true
    name: "Gate Status DC"
    id: gate_status_dc
    internal: false

#         Duty Cycle    Period / s
  - platform: template
    update_interval: 1s
    name: "Gate Status TM"
    id: gate_state
    lambda: |-
      if (id(gate_status_dc).state == 0) {
        return 0;
      } else if (id(gate_status_dc).state < 20) {
        return 1;
      } else if (id(gate_status_dc).state < 60) {
        return 2;
      } else {
        return 3;
      }

    ## ADC for Battery Voltage Sensor    
  - platform: adc
    id: gate_battery_voltage_sensor
    name: "Gate Battery Voltage"
    pin: 26
    unit_of_measurement: "V"
    update_interval: 1s
    filters:
      - calibrate_linear:
          - 0.4776 ->  4.826
          #- 0.9876 -> 10.009
          #- 1.1852 -> 12.011
          #- 1.2842 -> 13.012
          - 1.8684 -> 18.946
      - median:
          window_size: 5
          send_every: 4
          send_first_at: 2
      - exponential_moving_average:
          alpha: 0.1
          send_every: 1

  - platform: internal_temperature
  #- platform: adc
    id: gate_CPU_Temp
    #pin: TEMPERATURE
    name: "Gate CPU Core Temperature"
    update_interval: 30s
    unit_of_measurement: "°C"
    entity_category: "diagnostic"
    device_class: "volume"
    state_class: "measurement"
    filters:
      - lambda: return 27 - (x - 0.706f) / 0.001721f;

  - platform: wifi_signal # Reports the WiFi signal strength/RSSI in dB
    id: gate_wifi_signal_db
    name: "Gate WiFi Signal dB"
    update_interval: 5s
    unit_of_measurement: "dB"
    entity_category: "diagnostic"
    device_class: "SIGNAL_STRENGTH"
    state_class: "measurement"

  - platform: copy # Reports the WiFi signal strength in %
    source_id: gate_wifi_signal_db
    name: "Gate WiFi Signal Percent"
    filters:
      - lambda: return min(max(2 * (x + 100.0), 0.0), 100.0);

    unit_of_measurement: "%"
    entity_category: "diagnostic"

Anything in the logs that might be useful for us?

No logs since device is not booting

Additional information

The yaml code was working on the previous version of esphome but stopped rebooting after update this morning.

billmaterial commented 1 year ago

I too have this problem, I have 2 ESP32's and 1 test Pi Pico W. Both ESP32's reconnect a few seconds after an OTA update but the Pico will not reconnect until I power cycle it or the standard reboot_timeout limit is reached which I think is 15 minutes. I have set them all up as simple light/status light and WiFi signal strength devices. As a temporary measure I added this to my YAML file, not the best solution as it may boot loop every minute with no connection.

api: reboot_timeout: 1min

I hope someone more experienced than me can solve this issue!

si458 commented 1 year ago

im having the same issue with my test pico-w updated to 2023.3.0, now it wont connect to wifi at all, tried @billmaterial suggestion but doesnt work either any suggestions how to debug the pico w or rollback?

Niel1234 commented 1 year ago

I have the same problem config worked yesterday on 2023.2 and now after an update to 2023.3 it boot loops. If I flash my old.UF2 compiled on 2023.2 it boots up and is detected in home assistant

A new test config with no changes also has the same problem

Any update on a solution?

billmaterial commented 1 year ago

Also the OTA update feature is now broken, download stops at between 1%-3% every time. Need some way to roll back!

freddiemare commented 1 year ago

As per my code, the onboard LED is supposed to come on after boot on_boot: priority: -100.0 then:

I need to get my gat functional again, please.

billmaterial commented 1 year ago

@freddiemare I have tried everything to get this working. I managed to get the WiFi connecting again however the Pico W kept on rebooting but the OTA never worked. The solution that has worked for me was to restore from the backup created when the update to 2023.3.0 was applied. I am now back to running ESPHome 2023.2.4 and everything is working again as far as I know.........

si458 commented 1 year ago

@billmaterial ive got my working by doing the same thing, restored from old backup!

  1. restored the addon backup (2023.2.4)
  2. restarted my pi 4
  3. clicked update on my pico in esphome
  4. built via download (NOT WIRELESS)
  5. downloaded u2f file
  6. plugged pico w into laptop with BOOTSEL held,
  7. copied the u2f file to the pico
  8. popped right back up in home assistant
freddiemare commented 1 year ago

@billmaterial thank you for your testing effort I just restored back to 2023.2.4 and have to reprogram all my devices will give my experience later. will do the same as you @si458.

I do look forward to 2023.#.# update with the new features, requests, and also hopefully the resolution to the annoying reboot required that is a native thing to the esphome framework after the loss of connection and the API inevitably never reconnects since the device does reconnect back to the wifi. Hold thumbs up for this one...

freddiemare commented 1 year ago

Maybe some clue here

INFO Reading configuration /config/esphome/plot35gate.yaml...
INFO Generating C++ source...
INFO Compiling app...
Can not remove temporary directory `/data/plot35gate/.pioenvs`. Please remove it manually to avoid build issues
Processing plot35gate (board: rpipicow; framework: arduino; platform: https://github.com/maxgerhardt/platform-raspberrypi.git)
--------------------------------------------------------------------------------
Error: Traceback (most recent call last):
  File "/usr/local/lib/python3.9/dist-packages/platformio/__main__.py", line 102, in main
    cli()  # pylint: disable=no-value-for-parameter
  File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.9/dist-packages/platformio/cli.py", line 71, in invoke
    return super().invoke(ctx)
  File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/click/decorators.py", line 26, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/platformio/run/cli.py", line 147, in cli
    process_env(
  File "/usr/local/lib/python3.9/dist-packages/platformio/run/cli.py", line 204, in process_env
    result = {"env": name, "duration": time(), "succeeded": ep.process()}
  File "/usr/local/lib/python3.9/dist-packages/platformio/run/processor.py", line 83, in process
    install_project_env_dependencies(
  File "/usr/local/lib/python3.9/dist-packages/platformio/package/commands/install.py", line 131, in install_project_env_dependencies
    _install_project_env_platform(project_env, options),
  File "/usr/local/lib/python3.9/dist-packages/platformio/package/commands/install.py", line 148, in _install_project_env_platform
    PlatformPackageManager().install(
  File "/usr/local/lib/python3.9/dist-packages/platformio/package/manager/platform.py", line 50, in install
    pkg = super().install(spec, force=force, skip_dependencies=True)
  File "/usr/local/lib/python3.9/dist-packages/platformio/package/manager/_install.py", line 47, in install
    self.lock()
  File "/usr/local/lib/python3.9/dist-packages/platformio/package/manager/base.py", line 96, in lock
    self.ensure_dir_exists(os.path.dirname(self.package_dir))
  File "/usr/local/lib/python3.9/dist-packages/platformio/package/manager/base.py", line 127, in ensure_dir_exists
    os.makedirs(path)
  File "/usr/lib/python3.9/os.py", line 215, in makedirs
    makedirs(head, exist_ok=exist_ok)
  File "/usr/lib/python3.9/os.py", line 225, in makedirs
    mkdir(name, mode)
FileNotFoundError: [Errno 2] No such file or directory: '/data/cache'

============================================================

An unexpected error occurred. Further steps:

* Verify that you have the latest version of PlatformIO using
  `pip install -U platformio` command

* Try to find answer in FAQ Troubleshooting section
  https://docs.platformio.org/page/faq/index.html

* Report this problem to the developers
  https://github.com/platformio/platformio-core/issues

============================================================
freddiemare commented 1 year ago

Also Restored core_2023.3.3 then rebuild of the previous version for pi pico w device will work.

Icesythe7 commented 1 year ago

Also Restored core_2023.3.3 then rebuild of the previous version for pi pico w device will work.

no need to roll back 2023.3.4 is fine only need to roll back esphome and then reboot system, then clean build files (which will fix ur error above) then recompile firmware

jweston2112 commented 1 year ago

I too have this problem as well I mentioned it during the Beta .... I thought it was my ili9341 display since there were changes to that platform... but since then I have discovered it isnt related to that at all...

freddiemare commented 1 year ago

Hi @Icesythe7 I did rollback esphome and did reboot the complete system and started up from power up and cleaned out all old build files that are when I saw the above error on all my devices I then tried to do a backup restore and that failed then that is when I rolled back to core_2023.3.3 and again reboot then all device code build without any errors I will reinstall core_2023.3.4 tomorrow but at this point, my system is 100% stable now.

operinko commented 1 year ago

I wish I'd run into this issue before I updated the code on my garage door opener. Had to do some creative unassembly to get a USB cable to the device and re-flash it with a uf2 file. Thankfully I had a laptop to do it with, otherwise it would've been even worse :D For me, USB-to-serial interface was also dead, requiring me to do the upload with a manual file copy.

But, can confirm: 2023.3.X has an issue with picow, downgrading to 2023.2.3 and rebuilding the device firmware works. Even if the device is stuck in a state that requires a by-file-update instead of an OTA or serial.

Icesythe7 commented 1 year ago

I wish I'd run into this issue before I updated the code on my garage door opener. Had to do some creative unassembly to get a USB cable to the device and re-flash it with a uf2 file. Thankfully I had a laptop to do it with, otherwise it would've been even worse :D For me, USB-to-serial interface was also dead, requiring me to do the upload with a manual file copy.

But, can confirm: 2023.3.X has an issue with picow, downgrading to 2023.2.3 and rebuilding the device firmware works. Even if the device is stuck in a state that requires a by-file-update instead of an OTA or serial.

yep I had to disassemble and bring the pico inside and reflash it because no laptop :(

probot-esphome[bot] commented 1 year ago

Hey there @esphome/core, mind taking a look at this issue as it has been labeled with an integration (preferences) you are listed as a code owner for? Thanks! (message by CodeOwnersMention)

jesserockz commented 1 year ago

So it seems like even though nothing changed for the pico in a while, the flash_range_erase is hanging, causing the watchdog to trigger (after ~8.3 seconds) causing the reboot.

Still investigating what changed to cause this.

jesserockz commented 1 year ago

Possibly this is caused by https://github.com/esphome/esphome/pull/4410 which introduced including FreeRTOS for the rp2040.

freddiemare commented 1 year ago

Pi Pico W esphome update to 2023.3.1 seems to work ok will do more testing and note my findings, thanks for the update guy's

billmaterial commented 1 year ago

FYI, I have updated ESPHome to 2023.3.1 then updated all my devices, a mix of ESP32's and PicoW's (RP2040) and I can confirm they all work. If I subsequently encounter any issues I will report them here. Thank you @jesserockz awesome work !!!

nepozs commented 1 year ago

@jesserockz For me only manual flash works, no more OTA nor local upload when connected to HA USB (all methods worked OK in 2023.2.4).

logs_rpi-pico-w_logs_after_manual_download.txt

logs_rpi-pico-w_run_dowload_local_USB_port.txt

logs_rpi-pico-w_run_OTA_1.txt

logs_rpi-pico-w_run_OTA_2_after_retry.txt

Used YAML

esphome:
  name: "rpi-pico-w"
  friendly_name: "rpi-pico-w"

rp2040:
  board: rpipicow
  framework:
    # Required until https://github.com/platformio/platform-raspberrypi/pull/36 is merged
    platform_version: https://github.com/maxgerhardt/platform-raspberrypi.git

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  power_save_mode: none
  output_power: 14
  # Enable fallback hotspot in case wifi connection fails
  ap:
    ssid: "Rpi-Pico-W Fallback Hotspot"
    password: secret !wifi_rcvr

time:
  platform: homeassistant

#i2c:
#  - id: bus_a
#    sda: SDA #4
#    scl: SCL #5
#    scan: true
#  - id: bus_b
#    sda: SDA1 #26
#    scl: SCL1 #27
#    scan: true

#switch:

# ten switch wywala konfig ###
#  - platform: restart
#    name: "RPi Pico W Restart"

button:
  - platform: restart
    name: "RPi Pico W Restart"

binary_sensor:
  - platform: status
    name: "RPi Pico W Node Status"
    id: system_status

sensor:
  - platform: internal_temperature
    name: "Internal RPi pico W Temperature"
    accuracy_decimals: 1

  - platform: wifi_signal
    name: "RPi Pico W sygnał WiFi"
    update_interval: 60s

  - platform: uptime
    name: "RPi Pico W Uptime"
    filters:
      - lambda: return x / 3600;
    unit_of_measurement: "h"

status_led:
  pin:
    number: LED #32
    inverted: true
nepozs commented 1 year ago

@jesserockz Two strange things

nepozs commented 1 year ago

@freddiemare @billmaterial Could you test OTA and/or USB update direct from HA host I think issue should be reopened…

billmaterial commented 1 year ago

@nepozs I am now running ESPHome 2023.3.2 and HA 2023.3.6, I can confirm I have no issues with OTA updating both the PicoW and ESP32. I cannot check USB update from the HA host machine currently but can confirm USB update from another device does work for me.

nepozs commented 1 year ago

Thanks I am also now running ESPHome 2023.3.2 and OTA now works (but not with 100% success, anyway unsuccessful OTA does not lead to bootloop) , but update using direct USB connection still ends with bootloop. edit: freeze

billmaterial commented 1 year ago

@nepozs I have tried this out with only a PicoW, here are my results:

"Wirelessly": works "Plug into this computer": No option it is greyed out "Plug into the computer running ESPHome Dashboard": detects the device but fails to download "Manual Download" (other PC using .uf2 file): works

nepozs commented 1 year ago

Yes, in fact it is not bootloop, but RPi pico W is just frozen… (so it needs power cycle)

INFO Reading configuration /config/esphome/rpi-pico-w.yaml...
INFO Detected timezone 'Europe/Warsaw'
INFO Generating C++ source...
INFO Compiling app...
Processing rpi-pico-w (board: rpipicow; framework: arduino; platform: https://github.com/maxgerhardt/platform-raspberrypi.git)
--------------------------------------------------------------------------------
HARDWARE: RP2040 133MHz, 264KB RAM, 2MB Flash
 - framework-arduinopico @ 1.20604.0 (2.6.4) 
 - tool-rp2040tools @ 1.0.2 
Flash size: 2.00MB
Sketch size: 1.00MB
Filesystem size: 1.00MB
Maximium Sketch size: 1044480 EEPROM start: 0x101ff000 Filesystem start: 0x100ff000 Filesystem end: 0x101ff000
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
Dependency Graph
|-- WiFi @ 1.0.0
|   |-- Updater @ 1.0
|   |   |-- MD5Builder @ 1.0.0
|   |   |-- LittleFS @ 0.1.0
|   |   |-- PicoOTA @ 1.0.0
|   |   |   |-- LittleFS @ 0.1.0
|   |-- MD5Builder @ 1.0.0
|   |-- lwIP-Ethernet @ 1
|   |   |-- lwIP_CYW43 @ 1
|   |   |   |-- SPI @ 1.0
|   |   |-- SPI @ 1.0
|   |-- lwIP_CYW43 @ 1
|   |   |-- SPI @ 1.0
|   |-- SPI @ 1.0
|-- LEAmDNS @ 1.2
|   |-- lwIP-Ethernet @ 1
|   |   |-- lwIP_CYW43 @ 1
|   |   |   |-- SPI @ 1.0
|   |   |-- SPI @ 1.0
|   |-- WiFi @ 1.0.0
|   |   |-- Updater @ 1.0
|   |   |   |-- MD5Builder @ 1.0.0
|   |   |   |-- LittleFS @ 0.1.0
|   |   |   |-- PicoOTA @ 1.0.0
|   |   |   |   |-- LittleFS @ 0.1.0
|   |   |-- MD5Builder @ 1.0.0
|   |   |-- lwIP-Ethernet @ 1
|   |   |   |-- lwIP_CYW43 @ 1
|   |   |   |   |-- SPI @ 1.0
|   |   |   |-- SPI @ 1.0
|   |   |-- lwIP_CYW43 @ 1
|   |   |   |-- SPI @ 1.0
|   |   |-- SPI @ 1.0
|-- Updater @ 1.0
|   |-- MD5Builder @ 1.0.0
|   |-- LittleFS @ 0.1.0
|   |-- PicoOTA @ 1.0.0
|   |   |-- LittleFS @ 0.1.0
|-- noise-c @ 0.1.4
|   |-- libsodium @ 1.10018.1
|-- MD5Builder @ 1.0.0
Flash size: 2.00MB
Sketch size: 1.00MB
Filesystem size: 1.00MB
Maximium Sketch size: 1044480 EEPROM start: 0x101ff000 Filesystem start: 0x100ff000 Filesystem end: 0x101ff000
RAM:   [===       ]  26.5% (used 69496 bytes from 262144 bytes)
Flash: [====      ]  43.9% (used 458820 bytes from 1044480 bytes)
Building /data/rpi-pico-w/.pioenvs/rpi-pico-w/firmware.bin.signed
========================= [SUCCESS] Took 8.21 seconds =========================
INFO Successfully compiled program.
Processing rpi-pico-w (board: rpipicow; framework: arduino; platform: https://github.com/maxgerhardt/platform-raspberrypi.git)
--------------------------------------------------------------------------------
HARDWARE: RP2040 133MHz, 264KB RAM, 2MB Flash
 - framework-arduinopico @ 1.20604.0 (2.6.4) 
 - tool-mklittlefs-rp2040-earlephilhower @ 5.100300.230216 (10.3.0) 
 - tool-openocd-rp2040-earlephilhower @ 5.100300.230216 (10.3.0) 
 - tool-rp2040tools @ 1.0.2 
Flash size: 2.00MB
Sketch size: 1.00MB
Filesystem size: 1.00MB
Maximium Sketch size: 1044480 EEPROM start: 0x101ff000 Filesystem start: 0x100ff000 Filesystem end: 0x101ff000
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
Dependency Graph
|-- WiFi @ 1.0.0
|   |-- Updater @ 1.0
|   |   |-- MD5Builder @ 1.0.0
|   |   |-- LittleFS @ 0.1.0
|   |   |-- PicoOTA @ 1.0.0
|   |   |   |-- LittleFS @ 0.1.0
|   |-- MD5Builder @ 1.0.0
|   |-- lwIP-Ethernet @ 1
|   |   |-- lwIP_CYW43 @ 1
|   |   |   |-- SPI @ 1.0
|   |   |-- SPI @ 1.0
|   |-- lwIP_CYW43 @ 1
|   |   |-- SPI @ 1.0
|   |-- SPI @ 1.0
|-- LEAmDNS @ 1.2
|   |-- lwIP-Ethernet @ 1
|   |   |-- lwIP_CYW43 @ 1
|   |   |   |-- SPI @ 1.0
|   |   |-- SPI @ 1.0
|   |-- WiFi @ 1.0.0
|   |   |-- Updater @ 1.0
|   |   |   |-- MD5Builder @ 1.0.0
|   |   |   |-- LittleFS @ 0.1.0
|   |   |   |-- PicoOTA @ 1.0.0
|   |   |   |   |-- LittleFS @ 0.1.0
|   |   |-- MD5Builder @ 1.0.0
|   |   |-- lwIP-Ethernet @ 1
|   |   |   |-- lwIP_CYW43 @ 1
|   |   |   |   |-- SPI @ 1.0
|   |   |   |-- SPI @ 1.0
|   |   |-- lwIP_CYW43 @ 1
|   |   |   |-- SPI @ 1.0
|   |   |-- SPI @ 1.0
|-- Updater @ 1.0
|   |-- MD5Builder @ 1.0.0
|   |-- LittleFS @ 0.1.0
|   |-- PicoOTA @ 1.0.0
|   |   |-- LittleFS @ 0.1.0
|-- noise-c @ 0.1.4
|   |-- libsodium @ 1.10018.1
|-- MD5Builder @ 1.0.0
Flash size: 2.00MB
Sketch size: 1.00MB
Filesystem size: 1.00MB
Maximium Sketch size: 1044480 EEPROM start: 0x101ff000 Filesystem start: 0x100ff000 Filesystem end: 0x101ff000
RAM:   [===       ]  26.5% (used 69496 bytes from 262144 bytes)
Flash: [====      ]  43.9% (used 458820 bytes from 1044480 bytes)
Configuring upload protocol...
AVAILABLE: cmsis-dap, jlink, picoprobe, picotool, raspberrypi-swd
CURRENT: upload_protocol = picotool
Looking for upload port...
Using manually specified: /dev/ttyACM0
Forcing reset using 1200bps open/close on port /dev/ttyACM0
Uploading /data/rpi-pico-w/.pioenvs/rpi-pico-w/firmware.elf
rp2040load 1.0.1 - compiled with go1.15.8
.....................
*** [upload] Error 1
========================= [FAILED] Took 18.95 seconds =========================

So maybe it needs separate issue…