Проблемы с прошивкой flash-памяти обычно непросто устранить. Ниже приедены несколько советов по решению распространенных проблем.

[Загрузчик не отвечает]

Если в serial-консоли появляются ошибки наподобие "Failed to connect", то возможно чип не может правильно запустить загрузчик:

• Проверьте, что в командной строке утилиты монитора (обычно это скрипт idf.py) правильно указано имя последовательного порта.
• Проверьте, что у Вас есть разрешения на доступ к последовательному порту, и что какое-то другое программное обеспечение (такое как modem-manager на Linux) не пытается взаимодействовать с нужным последовательным портом. Часто бывает, что в другом окне уже открыто забытое соединение с используемым портом, и второе подключение создать не удается.
• Проверьте, что на чипе присутствует питание 3.3V от стабилизированного источника (см. далее "Плохое питание").
• Проверьте, что все выводы чипа подключены так, как описано в документации по выбору режима загрузки [2]. Проверьте напряжения на каждом выводе мультиметром или осциллографом, ножки с лог. 1 должны иметь напряжение, близкое к 3.3V, и ножки с лог. 0 близкое к 0V.
• Если к выводам GPIO чипа подключены другие устройства, попробуйте их отключить, и проверьте, заработает ли соединение с загрузчиком.
• Попробуйте уменьшить скорость соединения. Скорость 9600 самая маленькая допустимая скорость для соединения с загрузчиком, обычно используемая для отладки проблем скорости serial-соединения (настройте baud rate опцией -b 9600 скрипта idf.py).

[Случайные ошибки в процессе записи flash]

Если при записи происходят сбои, попробуйте уменьшить скорость подключения к последовательному порту. Также причиной случайных сбоев могут быть проблемы с питанием (см. "Плохое питание").

[Запись произошла успешно, но приложение не запускается]

Если esptool может прошить Ваш модуль командой write_flash, но программа не запускается, то проверьте следующее:

Неправильно выбранный режим SPI flash. Некоторые устройства поддерживают только режим прошивки dio. Запись во flash в режиме qio происходит успешно, но чип не может обратно прочитать flash, чтобы запустить программу - так что загрузка приложения не происходит. Попробуйте передать опцию -fm dio в команду write_flash.

См. документацию [3] для получения полного описания режимов flash, и как определить, какие из них поддерживает Ваше устройство.

Плохое питание. Чип ESP может потреблять от 3.3V достаточно большой ток (до 70 мА непрерывно, 200 .. 300 мА в пике, или даже больше). На шине питания должен присутствовать конденсатор достаточной емкости, чтобы сгладить спады по питанию в пиках потребления тока.

Если Вы используете предварительно собранную отладочную плату или модуль, то установленный на плате регулятор напряжения может предоставлять недостаточную мощность, чтобы обеспечить стабильную работу системы. На модулях от Espressif и других известных поставщиков обычно такой проблемы нет. Однако в некоторых случаях модули, наподобие ESP-WROOM02 и ESP-WROOM32, могут потребовать подключения снаружи дополнительного блокирующего конденсатора.

Выход 3.3V адаптеров USB-UART (например FTDI FT232R), или плат Arduino часто не предоставляет достаточной мощности по питанию.

[Отсутствует загрузчик]

ESP-IDF использует загрузчик второй стадии, работающий после заводского аппаратного, который находится в постоянной памяти чипа (boot ROM). На ESP32 образ загрузчика должен быть прошит со смещением 0x1000 относительно начала памяти flash. Среда разработки ESP-IDF делает это автоматически после выполнения соответствующих команд компиляции и прошивки (idf.py build flash). См. документацию ESP-IDF для получения информации, какие двоичные файлы нужно прошить, и по какому смещению (также см. [4]).

[Проблемы с сигналами SPI]

В сравнении с ROM bootloader, утилита esptool и работающий код загрузчика второй стадии использует намного больше внешних выводов, чтобы обмениваться данными с SPI flash.

Если используется режим "Quad I/O" (-fm qio, что esptool использует по умолчанию), то для доступа к SPI flash используются выводы GPIO7, GPIO8, GPIO9 и GPIO10, и они не должны использоваться для других целей. Если установлен режим "Dual I/O" (-fm dio), то используются GPIO7 и GPIO8, и они не должны использоваться для других целей.

Попробуйте отключить все постороннее от этих выводов. Попробуйте поменять режим "Dual I/O", если использовался "Quad I/O", или наоборот. Проверьте целостность сигналов подключений к памяти SPI flash, отсутствие замыканий между ними и на другие цепи. Имейте в виду, что если GPIO9 и GPIO10 также подключены к входным выводам чипа SPI flash, их все еще нельзя использовать как порты ввода/вывода общего назначения.

В дополнение к этим выводам, ножки GPIO6 и GPIO11 также используются для доступа к SPI flash (во всех режимах). Если эти выводы подключены неправильно, то прошивка обычно не работает.

[Сбой на ранней стадии загрузки]

Используйте программу последовательного терминала, чтобы просмотреть сообщения лога загрузчика (ESP32 использует скорость 115200 bps). Это позволит увидеть сообщения об ошибке и понять причину сбоя загрузки или запуска программы.

[Трассировка взаимодействий esptool]

Запуск esptool.py --trace будет выводить дамп всех последовательных интерактивных взаимодействий в стандартный вывод (данных будет выводиться довольно много). Это полезно для отладки проблем с последовательным соединением, или когда предоставляете информацию для техподдержки в виде bug-репорта.

Для дополнительной информации см. секцию "Tracing Esptool Serial Communications" документации по последовательному протоколу [7].

[Часто встречающиеся ошибки]

Ниже приведен не исчерпывающий список самых частых ошибок esptool с объяснением возможных причин и способов устранения. Перед тем, как предпринять какие-либо действия по исправлению, выполните все ранее перечисленные указания.

No serial data received. Утилита esptool не принимает никакие байты данных, или не может успешно принять пакет SLIP [7]. Эта ошибка обычно означает какую-то аппаратную проблему (перепутаны ножки RX/TX, или не подключены). Проверьте уровни сигналов и их наличие осциллографом, а также нет ли проблем со сбросом и выбором режима загрузки после сброса [2].

Wrong boot mode detected (0xXX)! The chip needs to be in download mode. В этом случае обмен с чипом работает (виден лог ROM boot), но чип автоматически не сбрасывается в режим загрузки.

Для решения проблемы проверьте схему автосброса (если на Вашей плате она есть), или попробуйте вручную выполнить сброс в режим загрузки. Как это делать, см. секцию "Manual Bootloader" документации [2].

Download mode successfully detected, but getting no sync reply: The serial TX path seems to be down. Чип успешно сбрасывается в режим загрузки и посылает данные компьютеру хоста, но не получает ничего в ответ от утилиты esptool. Это означает наличие проблемы с сигналом передачи от хоста к устройству ESP (RX ESP32 и TX адаптера USB-UART). Еще раз проверьте вашу плату и сигналы последовательного порта.

Invalid head of packet (0xXX): Possible serial noise or corruption. Причины этой ошибки могут быть следующие:

• Некачественный кабель USB.
• Иногда на плате макетирования могут замыкать ножки SPI flash, создавая подобную проблему. Попробуйте извлечь плату разработки из платы макетирования.
• На чипе во время прошивки может сработать аппаратный детектор пониженного напряжения (brown out). Часто это бывает при подаче питания от 3.3V регулятора чипов FTDI, или наличие других проблем питания (см. выше секцию "Плохое питание").

Что можно сделать:

• Попробуйте выполнить синхронизацию и обмен на пониженной скорости, например esptool.py --baud 9600 ...
• Попробуйте вывести дамп трассировки запуском esptool.py --trace ..., и посмотрите, принимается ли что-нибудь обратно.
• Попробуйте пропустить стадию автодетекта чипа путем явного указания используемого кристалла. Например, запустите esptool.py --chip ESP32 ...

Pyserial is not installed ... Поскольку утилита esptool написана на Python, она пользуется многими стандартными библиотеками, которые у вас могут быть не установлены. Для этой ошибки достаточно установить модуль pyserial командой:

pip install pyserial

/dev/cu.usbserial-0001 failed to connect: Failed to connect to Espressif device: Wrong boot mode ... С такой ошибкой я столкнулся на Mac OS, когда портировал скрипт прошивки для ESP32 с Linux.

Решение проблемы: подобрать скорость подключения опцией -b. Для моего случая оказалось достаточно понизить скорость до 115200 бод (поменял -b 460800 на -b 115200).

Если ничего не помогает, то откройте тикет в службе техподдержки (open a new issue на GitHub).

[Ссылки]

1. ESP32 Troubleshooting site:docs.espressif.com.
2. Boot Mode Selection site:docs.espressif.com.
3. SPI Flash Modes site:docs.espressif.com.
4. ESP32: процесс запуска приложения.
5. serial.tools.miniterm site:pyserial.readthedocs.io.
6. Serial Connection site:docs.espressif.com.
7. Serial Protocol site:docs.espressif.com.
8. ESP32: как реализовать автозагрузку прошивки.