Это принципиальная схема Elephant Embedded S32K144. Сейчас проблема в том, что программа не запускается, а flash всё время остаётся пустой. После отпускания кнопки RESET напряжение RESET относительно земли составляет 1 В, что явно неверно.
Продавец говорит, что чип заблокирован, и на RESET будет выходной сигнал. Ниже приведена форма сигнала RESET относительно земли.
Но когда я прогнал процесс прошивки через GPT, он сказал мне, что чип не заблокирован, flash можно прошить, но сразу после этого она стирается.
Когда я дал GPT весь процесс целиком, он объяснил это так: цикл сброса чипа вызван не watchdog, а LOCKUP reset — CPU с пустой flash выполняет выборку инструкции по адресу 0xFFFFFFFE → ошибка шины → HardFault (обработчик также находится по адресу 0xFFFFFFFE) → рекурсия → LOCKUP → reset → повторение цикла; период составляет несколько сотен микросекунд.
Но предложенные решения не помогли. Уважаемые специалисты, кто-нибудь знает, как это исправить?
Сброс по IO постоянно удерживается на низком уровне? Возможно, записанная вами программа использует IO PTA5 (RST), программно удерживает этот IO на низком уровне, а при этом в программе не отключена функция сброса для этого IO, из-за чего устройство всё время перезагружается? Попробуйте записать обычный тестовый пример.
Это напряжение RESET 1 В действительно подозрительное. В норме после отпускания кнопки сброса RESET должен подтягиваться внутренним подтягивающим резистором или внешним подтягивающим резистором почти до VCC (3,3 В). 1 В означает, что либо подтяжка слишком слабая, либо микросхема внутри постоянно удерживает сброс в низком уровне.
Если посмотреть схему, подтягивающий резистор R7 на 2,2 кОм должен быть достаточно сильным, но учтите, что вывод RESET у S32K144 двунаправленный — сама микросхема тоже может активно удерживать сброс в низком уровне. Если это действительно цикл LOCKUP, то микросхема будет сама сбрасываться каждые несколько сотен микросекунд, и пилообразная волна 1,64 кГц на осциллографе, скорее всего, как раз это и есть.
Сначала проверьте несколько моментов:
-
Измерьте напряжение на обоих концах R7, чтобы убедиться, что подтягивающий резистор действительно подключен к VCC_MCU и напряжение в норме. Иногда из-за плохой пайки питания отладочной платы или нестабильного выхода LDO напряжение подтяжки оказывается недостаточным.
-
Отключите кнопку сброса и напрямую подключите вывод RESET перемычкой к VCC, затем посмотрите, сможет ли программа работать. Если сможет, значит проблема в цепи сброса; если всё равно не сможет, проблему с цепью сброса можно исключить.
-
Подключитесь напрямую через J-Link или PE-отладчик, не через встроенный OpenSDA, и посмотрите, определяется ли ID микросхемы. Иногда встроенный отладчик мешает работе сброса.
-
Проверьте VDDA и VREFH: если аналоговое питание S32K144 не подключено или нестабильно, это тоже может вызывать странные поведения сброса.
По поводу цикла LOCKUP, о котором говорила GPT, логически это верно — пустая flash-память действительно может вести себя так. Но ключевой вопрос: почему flash оказалась пустой? Программатор не записал данные или записал, а потом они были стёрты? Рекомендую подключиться к микросхеме напрямую через J-Flash или S32 Design Studio и посмотреть, что именно находится во flash. Если flash действительно полностью заполнена FF, сначала запишите простейшую программу blink и проверьте, запустится ли она. Если запустится, значит микросхема не заблокирована, проблема в процессе прошивки; если не запустится, тогда уже рассматривайте возможное повреждение микросхемы или блокировку.
Объяснение GPT на самом деле точное. Пустая flash-память на S32K144 приводит к выборке по недопустимому адресу, из-за чего возникает HardFault, который перерастает в Lockup, а затем в сброс системы. МК активно удерживает этот вывод RESET на низком уровне, поэтому вы и видите пилообразную форму сигнала с частотой 1,64 кГц. Чтобы это исправить, вам нужен отладчик, поддерживающий «Connect under reset». Если вы используете J-Link, откройте J-Link Commander и попробуйте команду unlock kinetis. Она останавливает ядро до того, как оно попытается выполнить ошибочную инструкцию.
Та же самая плата, я в прошлом месяце сам на этом попался. Ваш анализ через GPT, по сути, довольно точный: это действительно цикл LOCKUP, но не дайте форме сигнала сброса сбить вас с толку.
Я тогда решил проблему так: во время прошивки удерживал кнопку сброса пальцем, нажал Download и сразу отпустил кнопку, чтобы код записался в чип до того, как сброс будет отпущен. Потому что как только запускается цикл LOCKUP, тайминги SWD сбиваются, отладчик считает, что запись прошла успешно, хотя на самом деле ничего не записалось. Потом при чтении всё оказывается 0xFF, и это выглядит так, будто память „стёрта“.
Кроме того, проверьте, является ли ваш файл запуска специфичным для S32K144. Если вы переносите код со STM32, возможно, неверно указано положение таблицы векторов или скрипт компоновки. Начальный адрес Flash у S32K144 — 0x0000_0000, но таблица векторов должна содержать допустимые начальные значения SP и Reset_Handler. Если эти два значения равны 0xFFFFFFFF, чип сразу после выхода из сброса перейдёт в HardFault.
Ещё проверьте, стабильны ли 3,3 В: эта плата при питании от USB иногда не вытягивает нагрузку. Когда напряжение проседает ниже 2,8 В, запись во Flash может молча завершаться ошибкой, и это тоже выглядит как „не прошивается“. Попробуйте более короткий USB-кабель или внешнее питание 5 В.
Это новая плата? Также возможно, что постоянные перезагрузки вызваны отсутствием прошивки.
У меня раньше такое было с ESP32S3: новый модуль, флеш-память пустая, и он постоянно перезагружался. Для ESP32 решение — включить питание, удерживая кнопку BOOT, чтобы перейти в режим прошивки.
Это дал начальник; он сказал, что никогда этим не пользовался.
Использовал официальный пример. Посмотрел PTA5 — он не настроен.
Пробовал: unlock Kinetis работает, но в flash всё равно не удаётся записать данные. Или они записываются, а потом снова стираются.
Спасибо, попробую завтра утром.