[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4061539#p4061539"]Откуда ж я знаю: хардфолт там или нет? Даже если б я и хотел gdb запустить, ни один из этих 10МК не работает с SWD. Про это я уже писал: прошиваю через бутлоадер.[/uquote] Ну тогда завести в RAM флаг (магическое значение по известному адресу), в регионе RAM который бутлоадер не трогает (это важно). В обработчике hardfault и чего там - прописать желаемое значение как индикатор что это было. После этого запустить фирмвару, ресет, через бутлоадер слить RAM и посмотреть что в этом месте. Более продвинутый вариант: exec trace, несколько флагов для прохождения ключевых точек, заодно и readback всех интересных регистров рядом сложить заодно можно, и похрен что UART не работает! Когда нихрена не понятно на ранней инициализации, а дебагера под рукой нет, можно за 5 минут накодить это и через 10 получить ответ на интересовавшие вопросы ранней инициализации. Единственное условие - чтобы RAM можно было считать без ее порчи потом. Бутлоадер в ROM для этого удобен
. Дело в том что RESET# сам по себе RAM не сбрасывает, и содержимое кто-то должен явно вынести. Бутлоадер протирает только лимитированный регион которым он пользуется. Нормальная фирмвара обычно делает это в startup для получения стандартного окружения и реинициализации, но не обязана. С теми или иными вариациями, например можно делать флаги переживающие ребут, типа запроса активации своего бутлоадера после ребута и т.п.. Главное чтобы стартап их не грохал. Единственное что если hardfault сам падает, тогда будет уже именно deadlock. Проверить полный deadlock можно... ну, например, каким-нибудь IRQ типа systick'а и хранением счетчика накручиваемого им в известном месте. Если deadlock, счетчик как я понимаю застрянет. Если же умер только main thread, systick продолжит тикать и крутить счетчик. И ему довольно пофиг на живость всего остального, кроме разве что может быть стэка. И то можно обработчикам отдельный резерв стэка дать через MSP, ARM так умеет.
Что до проверки регистра, то без разницы: счётчик или содержимое регистра проверять.
Не согласен. Счетчик "однопортовый". Его читает и пишет только софт. Поэтому он целиком под контролем софта. Регистр "двухпортовый" - железо с 1 стороны, софт с другой. И если идея в том что таймаут ловит заскоки железа, ожидать конкретное поведение железки само по себе странная идея, а конкретно так можно при случае сделать очень странный TOCTOU срабатывающий не так как вы думали раз в 10 лет. Тут его вроде нет, но я бы 100% не дал, откуда я знаю как чип на самом деле может. Регистры, биты которых которых вы ждете - совершенно точно могут меняться железом.
А если регистр настроек меняется "сам по себе", то такой МК нужно выкинуть!
Довольно забавная идея сказать это, попутно ожидая пока железо ... само поменяет бит в регистре?! И оно совершенно точно меняет регистр, вы как раз именно этого и ждете.
