Ошибка «Error occurred during flash mass erase» появляется в STM32CubeProgrammer или ST-LINK Utility в момент попытки полностью стереть Flash-память микроконтроллера STM32 — и чаще всего её причина кроется не в «сдохшем» чипе, а в активированной защите от чтения RDP (Readout Protection) или в некорректном подключении отладчика. Массовое стирание — первое действие любой прошивки, поэтому сбой на этом этапе полностью блокирует работу с устройством.
Проблема встречается как у любителей, прошивающих STM32F103 на «blue pill» через китайский клон ST-Link V2, так и у тех, кто восстанавливает кастомные платы после неудачной прошивки. Хорошая новость: в большинстве случаев микроконтроллер остаётся живым, и ошибку удаётся устранить программными методами. Разберём причины по порядку — от самых простых к более сложным.
Что означает эта ошибка
Команда Mass Erase инициирует полное стирание всех секторов Flash-памяти микроконтроллера. Контроллер Flash внутри чипа может отклонить эту команду, если действует защита, если ядро занято исполнением кода из Flash или если отладчик потерял связь с ядром в процессе операции.
Важно отличать эту ошибку от проблем соединения на уровне SWD: если STM32CubeProgrammer вообще не видит чип («No target connected»), это другая история. Здесь же подключение есть, ID микроконтроллера читается, но стирание завершается сбоем. Это сужает круг подозреваемых до защиты памяти, состояния option bytes и стабильности самого сеанса отладки.
Ошибка mass erase при успешном подключении к чипу почти всегда указывает на защиту RDP, проблемные option bytes или нестабильный сеанс SWD — а не на физическую неисправность микроконтроллера.
Причина 1: активная защита RDP (Readout Protection)
Наиболее частый сценарий — на микроконтроллере включён RDP Level 1. Эта защита блокирует доступ отладчика к Flash: чтение и стирание через SWD запрещены, пока защита активна. Защита могла быть включена предыдущей прошивкой (некоторые загрузчики и коммерческие прошивки делают это намеренно) либо случайно при записи option bytes.
Проверить состояние просто: в STM32CubeProgrammer откройте раздел OB (Option Bytes) и посмотрите значение RDP. Значение 0xAA означает отсутствие защиты (Level 0), любое другое значение, отличное от кода Level 2, — Level 1. Точные коды зависят от семейства STM32, поэтому сверяйтесь с reference manual на ваш конкретный чип.
Снятие Level 1 выполняется через установку RDP обратно в Level 0. При этом микроконтроллер автоматически выполняет полное стирание Flash — все данные будут безвозвратно удалены. Это штатное поведение защиты, а не сбой. После снятия защиты повторите mass erase — обычно операция проходит успешно.
⚠️ Внимание: если на чипе установлен RDP Level 2, защита снимается необратимо — отладочный интерфейс отключается навсегда, и прошить микроконтроллер через SWD больше не получится. Перед изменением option bytes обязательно проверьте текущий уровень защиты.
Причина 2: проблемы с подключением и питанием
Массовое стирание — энергоёмкая операция: во время неё микроконтроллер потребляет заметно больше тока, чем в простое. Если питание нестабильно, напряжение проседает, и операция прерывается с ошибкой. Особенно это актуально при питании платы напрямую от клона ST-Link V2, чей стабилизатор не всегда справляется с нагрузкой.
- 🔌 Проверьте, что на пины
VDDиVDDAмикроконтроллера подаётся стабильное питание, а все пиныVSS/GNDподключены. - 📏 Сократите длину проводов SWD до 10–15 см — длинные шлейфы дают помехи и обрывы связи.
- 🐢 Снизьте частоту SWD в настройках подключения (например, до минимального доступного значения) — медленное, но стабильное соединение лучше быстрого и рвущегося.
- 🔋 Запитайте плату от внешнего источника, а не от программатора, если на ней есть энергоёмкая периферия.
- 🔁 Попробуйте режим подключения
Connect Under Reset— он надёжно захватывает ядро до старта пользовательского кода.
Причина 3: состояние пинов BOOT и режим подключения
Если пользовательская прошивка сразу после старта переходит в сон, отключает тактирование отладочного интерфейса или переназначает пины SWDIO/SWCLK как обычные GPIO, отладчик теряет контроль над ядром в середине операции стирания. Внешне это выглядит именно как сбой mass erase.
Решение — загрузить микроконтроллер так, чтобы пользовательский код не запустился. Для этого используется пин BOOT0: подтяжка его к высокому уровню переводит чип в системный загрузчик, и прошивка из Flash не исполняется. Расположение и логика работы пинов BOOT различаются между семействами STM32 (у части серий вместо пина используются option bytes), поэтому уточните схему в datasheet на ваш чип.
Альтернатива без манипуляций с пинами — режим Connect Under Reset в STM32CubeProgrammer: отладчик удерживает чип в сбросе, подключается к ядру и только потом отпускает reset. Вам нужно выбрать этот режим в настройках подключения и повторить стирание. В связке с удержанием кнопки NRST на плате метод работает даже на «засыпающих» прошивках.
Если кнопки RESET на плате нет, в режиме Connect Under Reset помогает «горячее» подключение: запустите стирание в программе и в этот момент кратковременно замкните NRST на землю, затем отпустите.
Пошаговая инструкция по устранению
Действуйте от простого к сложному, проверяя результат после каждого шага. Не меняйте несколько параметров одновременно — иначе будет неясно, что именно помогло.
☑️ Порядок действий при ошибке mass erase
Первым делом подключитесь к чипу в STM32CubeProgrammer и убедитесь, что он стабильно определяется: несколько раз нажмите Connect/Disconnect. Если подключение нестабильно — решайте вопрос с проводами, питанием и частотой, прежде чем трогать option bytes.
Затем откройте раздел OB и проверьте RDP. При Level 1 переведите значение в Level 0 (0xAA для большинства семейств) и примените изменения — чип сам выполнит стирание. После этого повторите Erase → Mass erase через меню или кнопку полного стирания в разделе Erasing & Programming.
# Альтернатива через командную строку (STM32_Programmer_CLI):
STM32_Programmer_CLI -c port=SWD mode=UR -ob RDP=0xAA
STM32_Programmer_CLI -c port=SWD mode=UR -e all
Сравнение сценариев и методов восстановления
В таблице сведены типичные ситуации, их признаки и рекомендуемый первый шаг. Это ориентир для диагностики, а не абсолютная истина: поведение зависит от семейства чипа и конкретной платы.
| Симптом | Вероятная причина | Первый шаг |
|---|---|---|
| Чип определяется, стирание сразу падает | RDP Level 1 | Проверить и сбросить RDP в option bytes |
| Стирание начинается и обрывается | Просадка питания, помехи на SWD | Снизить частоту, улучшить питание |
| Ошибка только после своей прошивки | Код отключает SWD или уходит в сон | Connect Under Reset или BOOT0 |
| RDP не меняется, SWD недоступен | Возможен RDP Level 2 | Проверить код RDP; восстановление невозможно |
| Ошибка на новом чипе из партии | Брак, подделка, повреждение | Проверить другой экземпляр чипа |
Почему клоны ST-Link чаще дают эту ошибку
Бюджетные клоны ST-Link V2 часто имеют урезанную схемотехнику: нет буферов на линиях SWD, слабый стабилизатор питания, устаревшая прошивка самого отладчика. Обновление прошивки клона через STM32CubeProgrammer (если поддерживается) и питание целевой платы от отдельного источника заметно повышают стабильность сеансов стирания.
Когда программные методы не помогают
Если все перечисленные шаги выполнены, а ошибка сохраняется, возможны аппаратные причины: повреждённая Flash-память после превышения количества циклов перезаписи, электростатический пробой, некорректное напряжение питания в прошлом или поддельный микроконтроллер. На рынке встречаются перемаркированные чипы, которые определяются как STM32, но ведут себя непредсказуемо.
⚠️ Внимание: не пытайтесь «лечить» чип повышенным напряжением питания или длительным удержанием под питанием в нештатных режимах — это гарантированно выведет микроконтроллер из строя. Если чип из партии ведёт себя аномально, сравните его поведение с заведомо исправным экземпляром.
Практический тест прост: возьмите другой микроконтроллер той же модели (или другую плату) и повторите подключение тем же отладчиком и теми же проводами. Если второй чип стирается без ошибок — проблема в конкретном экземпляре. Если ошибка повторяется — ищите причину в отладчике, проводах или настройках.
Последовательность диагностики всегда одна: сначала питание и провода, затем режим подключения, затем option bytes и RDP, и только в конце — подозрение на неисправный чип.
Часто задаваемые вопросы
Удалятся ли мои данные при снятии RDP Level 1?
Да. Снятие защиты Level 1 аппаратно сопровождается полным стиранием Flash-памяти — это встроенный механизм безопасности STM32. Восстановить прошивку после этого невозможно.
Можно ли снять RDP Level 2?
Нет. Level 2 отключает отладочный интерфейс необратимо — это задокументированное поведение. Микроконтроллер останется работоспособным с залитой прошивкой, но перепрошить его через SWD не получится.
Ошибка возникает в Keil или при прошивке из IDE — это то же самое?
Да, суть та же: IDE вызывает стирание Flash через тот же отладчик. Проверяйте те же пункты — RDP, питание, режим подключения. Дополнительно полезно повторить стирание в STM32CubeProgrammer, чтобы исключить влияние настроек конкретной среды разработки.
Помогает ли стирание через UART-загрузчик (BOOT0)?
Часто да. Системный загрузчик STM32 поддерживает команды стирания через UART/USB (зависит от семейства). Если SWD-сессия нестабильна, подключение через системный bootloader с подтяжкой BOOT0 к высокому уровню — рабочий обходной путь. Набор интерфейсов загрузчика уточняйте в application note AN2606 для вашего семейства.
Чип новый, но mass erase падает — он бракованный?
Не обязательно. Сначала исключите проблемы подключения, питания и отладчика, проверив другой экземпляр чипа той же партии. Только если несколько чипов ведут себя одинаково плохо при исправном стенде, есть основания говорить о браке или подделке.