stm32 NVIC: сброс маскировки прерываний внутри обработчика Опции

[jeka]

Назрела необходимость (уже давно), разрешить прерывания более низкого приоритета в обработчике высокого приоритета. Способ в лоб - подкорректировав стек и сделать фиктивный возврат из прерывания.
С помощью MRS/MSR как я понял этого не сделать - в документации написано что запись в IPSR игнорируется.
Есть ли какое-то более человеческое решение чем через формирование стека возврата и возврат из прерывания?

Собственно, зачем это нужно - в случае аварии вызывается определенный irq. В обработчике нужно сделать некую аварийную последовательность действий, но для этого нужны рабочие обработчики другиз, в т.ч. низкоприоритетных прерываний. Можно конечно приоритеты нужных irq повысить.
Но есть вторая задача - сделать софтовый ресет (разумеется с обнулением стека), в нужную функцию и с разблокированными прерываниями. Например, в bootolader для перепрошивки.

[Forger]

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

Это противоречит самому принципу приоритетов прерываний. Странная необходимость ...

Способ в лоб - подкорректировав стек и сделать фиктивный возврат из прерывания.
С помощью MRS/MSR как я понял этого не сделать - в документации написано что запись в IPSR игнорируется.

В режиме handler (обработка прерываний) автоматом включается привилегированный режим, т.е. при остром желании можно влезть в любой стек и нагадить там как положено ))
Обычно это используют лишь в портах RTOS.

Есть ли какое-то более человеческое решение чем через формирование стека возврата и возврат из прерывания?

Можно форсить более высокоприоритетное прерывание прямо из текущего обработчика.
В зависимости от его приоритета оно будет вызвано сразу или лишь после выхода из текущего обработчика.
Для этой цели хорошо подойдет NMI, у него самый высокий приоритет (после Reset).
Можно даже извратиться - вызывать hardfault, например, обращаясь к несуществующей памяти

Собственно, зачем это нужно - в случае аварии вызывается определенный irq.

А в чем проблема вызывать некую функцию? К чему городить огород с отдельным прерыванием?

Например, в bootolader для перепрошивки.

А вот эта задача реализуется уже несколько иначе. Тут неоднократно поднималась эта тема. Пройдитесь поиском ))


зы. Подобную задачу я реализую просто: вызываю в случае аварии System Reset (нужно смотреть на его реализацию в каждом семействе МК).
Однако, не во всех задачах полный сброс допустим.
Аппаратно само устройство делаю так, что в сброшенном состоянии все силовые цепи отключаются, автоматом снимаются все сигналы готовности (если используются внешние силовые модули).
Это реализована подтяжками соотв. портов МК внешними резисторами.
Остальные обработчики типа HardFault у меня тоже в итоге вызывают System Reset (после анализа и фиксации в журнале событий причины сбоя).
Т.е. любое зависание, срабатывание вотчдога и т. д. всегда сбрасывают проц, что автоматом вырубает все силовые цепи.
Это удобно при отладке и прошивке - пока шьется проц, вырубается всякая опасная "сила", скажем силовые ключи привода мощного мотора, гасится мощной источник для "силы".
В таком решении гарантировано, что ничего никуда не поедет и не сожжет никакие "пробки" )))

[jeka]

Собственно в мягком ресете есть необходимость именно из-за сброса gpio - например, обрывается питание и bluetooth подвисает перед прошивкой. Плюс, все переменные переинициализируются и нельзя точку входа выбрать, неудобно.

То что колхоз это понятно, но без него не вижу простых решений. Хотя не сильный колхоз. Единственное неудобство - повторный вход в оборванные обработчики прерываний, но это не сильно пугает. Сброс состояний - дело несложное.

[Forger]

Единственное неудобство - повторный вход в оборванные обработчики прерываний, но это не сильно пугает. Сброс состояний - дело несложное.

Все-таки не пойму, чем не годится обычная функция, которая делает всю эту инициализацию?

например, обрывается питание и bluetooth подвисает перед прошивкой

Я бы в таком случае поставил ключ на питание блютуса - какой нить подходящий p-mosfet.
Управление им от соотв. gpio. Так и питание батарейки проще экономить (если девайс батарейный).

[jeka]

п.с. irq вызывается, поскольку авария может прилететь извне в любой момент и независимо от режима работы нужно немедленно выполнить аварийные процедуры. Проще всего это сделать с чистого листа - заново принудительно с нуля переинициализировать нужную периферию (чтоб наверняка) в нужный режим, отключить все лишнее и сделать несколько действий.

[Forger]

п.с. irq вызывается, поскольку авария может прилететь извне в любой момент и независимо от режима работы нужно немедленно выполнить аварийные процедуры. Проще всего это сделать с чистого листа - заново принудительно с нуля переинициализировать нужную периферию (чтоб наверняка) в нужный режим, отключить все лишнее и сделать несколько действий.

Так все-таки, чем не годится вызов некой функции, где все это делается?
Она же вызывается при запуске проца однократно.

[jeka]

Я бы в таком случае поставил ключ на питание блютуса - какой нить подходящий p-mosfet.

как вариант, только с RC цепочкой. Чтоб вырубался, но не сразу. Но честно не думал что проблемы такого характера могут возникнуть, думаю все-таки правильнее программно решить.

[Forger]

как вариант, только с RC цепочкой. Чтоб вырубался, но не сразу. Но честно не думал что проблемы такого характера могут возникнуть, думаю все-таки правильнее программно решить.

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

В одном моем проекте стояла ESP-ка, которая любила иногда подвисать по usart-у. Зная это, я сразу поставил для нее отдельный стабилизатор 3.3В со входом EN.
Это позволило включать ESP-ку только тогда, когда это было нужно, чисто программно. Зависла - передергиваем питание стабилизаатора и начинаем все по-новой.
Фактически производился сброс только модуля, отвечающего за обмен под wifi, а все остальные модули (программные модули) работали в штатном режиме.

[jeka]

Так все-таки, чем не годится вызов некой функции, где все это делается?
Она же вызывается при запуске проца однократно.

Ей нужно по хорошему передать несколько параметров. Плюс как определить что на ребут для определенной цели ушел? В память записать определенную сигнатуру? Но это то же колхоз.

[Forger]

Ей нужно по хорошему передать несколько параметров.

Зачем?
Сделайте разные функции для разных задач. Дайте им соотв. имена.

Плюс как определить что на ребут для определенной цели ушел?

Я использую модульную структура проекта, каждый модуль нужно инициализировать индивидуально при старте.
Но ничто не мешает принудительно его переинициализировать (скажем, вызвав соотв. SWI).
Каждый модуль у меня "владеет" своими пинами и своими аппаратными узлами (таймеры, цапы и т.п.).
Никто не обращается к одному и тому же аппаратному узлу из разных модулей. Т. е. у всех аппаратных сущностей есть владелец в единственном числе.
Так я точно могу управлять всей системой. Т. е. на этапе проектировки закладывается строгая и очень жесткая иерархия.
Она неизменна в процессе работы всей железки.
Каждый модуль обязан самостоятельно инициализировать "свое" железо (в т.п. числе и пины!).
Общая пока что только инициализация системного таймера и тактовой частоты, но и она скоро "уйдет" в свой модуль (SystemController).

В память записать определенную сигнатуру? Но это то же колхоз.

Я совсем запутался ... Какую еще сигнатуру?
Что же на самом деле вы хотите реализовать?
Распишите конкретный пример, а то, может оказаться, что мы толкуем о разных вещах )))

[jeka]

Сейчас я в одном из девайсов делаю примерно так. Т.е. делаю софт-ресет из основного цикла (где контроллер irq не замаскирован), а в AHBENR ставлю флаг, который в загрузчике анализируется и после железного ресета гарантированно сброшен.

Код

        RCC->AHBENR=1;// marker for software reset
  
        SysTick->CTRL=0;
        uint32_t* ptr=(uint32_t*)(0x08000000);
        SCB->VTOR=(uint32_t)ptr;
        __set_MSP(*(ptr++));
        __set_BASEPRI(0);
        __set_CONTROL(0);
        NVIC->ICER[0]=0xFFFFFFFF;
        NVIC->ICER[1]=0xFFFFFFFF;
        NVIC->ICER[2]=0xFFFFFFFF;
        NVIC->ICER[3]=0xFFFFFFFF;
        NVIC->ICER[4]=0xFFFFFFFF;
        NVIC->ICER[5]=0xFFFFFFFF;
        NVIC->ICER[6]=0xFFFFFFFF;
        NVIC->ICER[7]=0xFFFFFFFF;
        NVIC->ICPR[0]=0xFFFFFFFF;
        NVIC->ICPR[1]=0xFFFFFFFF;
        NVIC->ICPR[2]=0xFFFFFFFF;
        NVIC->ICPR[3]=0xFFFFFFFF;
        NVIC->ICPR[4]=0xFFFFFFFF;
        NVIC->ICPR[5]=0xFFFFFFFF;
        NVIC->ICPR[6]=0xFFFFFFFF;
        NVIC->ICPR[7]=0xFFFFFFFF;
        void (*start)()=(void(*)())(*ptr);
        start();

Вполне доволен таким софтовым ресетом без сброса железа.

[Forger]

Вполне доволен таким софтовым ресетом без сброса железа.

А приведите пример, когда действительно нужен такой "софтовый ресет"?

[jeka]

Я совсем запутался ... Какую еще сигнатуру?
Что же на самом деле вы хотите реализовать?
Распишите конкретный пример, а то, может оказаться, что мы толкуем о разных вещах )))

Мы видимо по разному думаем.

Я про то, как передать загрузчику после железного ресета параметры. Это некий квест и тоже с колхозом.

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

[Forger]

После перепрошивки также без переинициализации протокола обмена запустить основную программу.

Имхо, очень сомнительная и где-то даже опасная необходимость ...
Обычно, всякая смена прошивки софта предполагает сброс всего проца. Мне никогда не попадалось обратное.

Но, может быть, вы имеете ввиду некие настройки конкретного экземпляра девайса?
У меня такие настройки храняться в внешней EEPROM/FRAM или во внутреннем EEPROM (или FLASH, если нету EEPROM).
При перезапуске приложения все настройки загружаются в ОЗУ и оттуда все работает до очередного сброса.
Также предусмотрены настройки по дефолту, позволяет вернуть девайс соотв. командами к заводским настройкам.
За все это отвечает отдельный модуль Settings, он хранит все изменяемые параметры системы, которые могут быть разные для разных девайсов (в т. ч. серийны номер).

Мы видимо по разному думаем.

Это вообще-то справедливо для всех, иначе вообще не были бы нужны форумы

[jeka]

Специфика такая. Не хочется протокол обмена обрывать, т.к. это вызывает проблемы на главном устройстве, а их решить сложнее чем протокол поддерживать.

[Forger]

Специфика такая. Не хочется протокол обмена обрывать, т.к. это вызывает проблемы на главном устройстве, а их решить сложнее чем протокол поддерживать.

А если сохранить параметры протокола в энергонезависимой памяти, а после сброса (даже аппаратного) восстановить их и продолжить с прерванного места?
Годится такое решение?

[jeka]

годится, но больно сложно получается. Плюс дополнительная блокировка обмена на этапе рукопожатия (пока трём и пишем страницу во flash) перед прошивкой может проблем добавить.

[Forger]

годится, но больно сложно получается.

Да неужели? Вот тут я бы поспорил, что сложнее ...

Плюс дополнительная блокировка обмена на этапе рукопожатия (пока трём и пишем страницу во flash) перед прошивкой может проблем добавить.

Обмен все равно придется прекратить на всё время обновления прошивки. Так в чем проблема приостановить обмен перед сохранение его параметров?

[jeka]

Ну не хочется городить огород с записью во флеш, правкой дисциплины обмена когда есть простое и работающее без нареканий на других процессорах решение. Решение меня не устраивало только тем что не хотел вставлять ассемблерную функцию. Пока варианта лучше нет, будет так.

[Forger]

... когда есть простое и работающее без нареканий на других процессорах решение.

Но тогда с какой целью затевалась эта тема?

[jeka]

Цель - понять, можно ли на arm сбросить маскировку прерываний кроме как командой возврата из прерывания. Хочется без костыля в виде функции на ассемблере обойтись.

[KSN]

По поводу непрерывного протокола обмена.
Делаю так: в RAM есть структура, которая не инициализируется средствами компилятора при старте программы. Через эту структуру bootloader и application обмениваются информацией( вызов bootloadera из application, возврат из bootloader в application). Использую какие-нибудь хитрые значения для этих переменных, а не простые 0x00000000, 0xFFFFFFFF, наподобие значение переменных для снятие блокировки с watch-dog, flash memory в stm32f.
Работает так: прилетает команда по интерфейсу "перейти в bootloder". Application отвечает, что команда принята, выполняет необходимы действия, устанавливает переменную и вызов bootloader. Bootloader "понимает" что был переход по команде, шлет по интерфейсу подтверждение исполнения команды и далее обрабатываются команды для bootloadera. После завершения обновления прошивки, приходит команда "выйти из bootloader" - посылается ответ, что команда принята, устанавливается переменная, выполняются необходимые действия и переход в Application. Application "понимает", что был выход из bootloadera по команде, шлет "подтверждение исполнения" команды и продолжает исполняться код приложения.

[jcxz]

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

А в чём проблема? Разрешаете через соотв. регистр NVIC и всё. У меня много где внутри одних ISR разрешаются/запрещаются другие.

Способ в лоб - подкорректировав стек и сделать фиктивный возврат из прерывания.

Не понял... %-\ Зачем???
Вам же надо вроде только разрешить некое другое прерывание, причём тут возврат из текущего?

[Forger]

По поводу непрерывного протокола обмена.
Делаю так: в RAM есть структура, которая не инициализируется средствами компилятора при старте программы.

Скажем, питание было выдернуто (передернуто) в процессе обмена данными через эту область ОЗУ и тем более в процессе заливки новой прошивки.
Есть защита от подобных сбоев?

[jcxz]

в документации написано что запись в IPSR игнорируется.

Если с умом подходить, то и в IPSR можно записать. Только - зачем?

Ей нужно по хорошему передать несколько параметров. Плюс как определить что на ребут для определенной цели ушел? В память записать определенную сигнатуру? Но это то же колхоз.

Почему "колхоз"?
Такой "колхоз" даже производители некоторых МК делают Например в Infineon, после передачи управления пользовательскому ПО из ROM-загрузчика, в начале ОЗУ гарантируется наличие некоторых данных (например - серийный номер чипа).
И в Вашем случае, для передачи неких команд управления вашему бутлоадеру вполне можно также делать. Но опять-же - с умом.
Например:
Обычно в МК есть флажки, позволяющие определить причину сброса (внешний reset, POR, WDT, etc.). Так вот: после старта бутлоадер может посмотреть на флажки и, если там указан WDT, проверить некую область ОЗУ на наличие ключа. Если причина сброса - не WDT, то не читать ключ. Соответственно в рабочей прошивке, сразу после получения управления, в область ключа записывается НЕ_ключ и спокойно работаем. Если пришла необходимость сделать переход в бутлоадер: формируем WDI, пишем в область ключа собственно ключ и делаем сброс по WDT.

[KSN]

Скажем, питание было выдернуто (передернуто) в процессе обмена данными через эту область ОЗУ и тем более в процессе заливки новой прошивки.
Есть защита от подобных сбоев?

Да, конечно. Проверка CRC прошивки, область bootloaderа защищена. При возникновение такой ситуации устройство перезагрузится, останется в bootloader, при этом по интерфейсу будет послано сообщение в систему.

[Obam]

Назрела необходимость (уже давно), разрешить прерывания более низкого приоритета в обработчике высокого приоритета…
Есть ли какое-то более человеческое решение чем через формирование стека возврата и возврат из прерывания?

Как возможность, вызов прерывания с достаточным приоритетом записью его номера в STIR: ваш обработчик высокого приоритета отработает, и будет исполняться тот, что из STIR.

[jeka]

Прошу прощения, не указал один важный момент, из-за которого путаница возникла: из обработчика прерывания высокого приоритета возврат не предполагается. Совсем. Предполагается не выходя из обработчика этого irq сделать фактически рестарт процессора и передачу управления нужному модулю с переинициализацией стека, контроллера прерываний и остальной периферии.

[Obam]

Тогда вообще ни о чём: сброс и всё.

[jeka]

Сброс не желателен, т.к. состояние части периферии нужно сохранить.

Вообще топик не про поиск обходных путей решения (это мне не нужно - придумать с десяток вариантов и сделать один из вариантов проблем не составляет), а про конкретную аппаратную особенность процессора, а именно сброс текущего приоритета прерываний без шаманства со стеком.

[Forger]

сброс не желателен, т.к. состояние части периферии нужно сохранить.

Так что мешает вызывать соотв. функцию, которая переинициализирует нужную периферию и в т.ч. NVIC.
Эта же функция должна вызывается при сбросе.
Вот тут я подробно описал как делаю нечто подобное, никакого колхоза, все прозрачно:
https://electronix.ru/forum/index.php?s=&am...t&p=1508140

[jeka]

Мешает то что если из обработчика прерывания просто передать управление стартовому коду (без system reset), то ненулевой IPSR не сбросится и часть прерываний будет перманентно заблокировано.

[Forger]

Мешает то что если из обработчика прерывания просто передать управление стартовому коду (без system reset), то ненулевой IPSR не сбросится и часть прерываний будет перманентно заблокировано.

А почему реально не сделать программный сброс (system reset)? Ведь содержимое внутреннего ОЗУ при этом вроде бы не теряется.

[Obam]

"сброс текущего приоритета прерываний без шаманства со стеком."
Рафинированное шаманство

[jcxz]

Мешает то что если из обработчика прерывания просто передать управление стартовому коду (без system reset), то ненулевой IPSR не сбросится и часть прерываний будет перманентно заблокировано.

Без формирования необходимого стекового фрейма тут не обойтись. Собственно именно такую операцию и выполняет таск-шедулер любой ОС, висящий на PendSV.
Вы можете сделать по образу и подобию:
Задействовать некий вектор прерывания (не используемого). Назначить ему приоритет заведомо ниже любого другого прерывания (самый низкий из всех).
Далее - в Вашем ISR возбуждаете это прерывание программно (через соотв. регистры NVIC) и штатно выходите из ISR.
Соответственно - сразу попадаете в тот низкий ISR, в нём корректируете стековый фрейм (кроме адреса возврата собственно больше ничего менять и не надо) и штатно выходите из этого ISR в нужную точку с корректным IPSR.
Никаких запретов прерываний, никакого шаманства - всё штатными средствами.

PS: Хотя лучше всё-таки подумать - зачем именно нужно так переходить, без сброса периферии. Это, имхо, идеологически неправильный подход

[AVI-crak]

Собственно, зачем это нужно - в случае аварии вызывается определенный irq.

На случай аварий - системой уже предусмотрено несколько стандартных аппаратных прерываний разного уровня. От мягких программных, до жёстких системных.

Собаку можно обработать программно, и успеть перевести внешнюю периферию в необходимое для выключение состояние. Например полностью блокировать внешний силовой драйвер мощных транзисторов, да и вообще отрубить всё питание.

Чтение мимо адресного пространства BusFault - можно поймать отладчиком, вернуться в точку остановки кода, и найти сбойное место. Часто причиной сбоя является неисправность указателей, тогда приходится искать намного дольше.

Модуль защиты MPU - на самом деле замечательная вещь, на M4-M7 без него никак. Дело в том что ядро обрабатывает программный код на конвейере, дополнительно - сам код собирается для внеочередного исполнения. GCC знает про MPU, и умеет использовать его настройки. Например для линейной области памяти управления почти всей периферией (0x40000000 - (0.5G)) - запрет кеша, сквозная запись, запрет обратной записи, запрет исполнения кода, ожидать выполнения физической записи. В этом случае состояние периферии будет меняться программой - как задумал пользователь, но не как удобно GCC. Дополнительно - конвейер команд будет сбрасываться при обнаружении обращения к области периферии - чтоб ни одна сволочь вперёд очереди не проскочила (типа я только спросить).
Если при таких настройках выполнить переход на адреса периферии (исполнение программного кода) - то сработает прерывание MemManage_Handler. Оно является мягким, и его можно обработать возвратом в программный код с поиском ошибки.

HardFault - являться жёстким отказом системы, его можно обработать ручным способом, и даже найти место сбоя - но невозможно исправить в реальном времени.

Ну и всё скопом по порядку:
Reset_Handler - стартовый адрес прошивки
NMI_Handler - неизвестное прерывание Default_Handler, любое из неопределённых
HardFault_Handler - отказы: шины, арбитра памяти, сбой чтения вектора прерываний.
MemManage_Handler - ошибка доступа к памяти, срабатывание правил MPU
BusFault_Handler - чтение/запись по недопустимому адресу
UsageFault_Handler - прерывание специально для пользователя, можно оформить как критическую секцию
часть прерываний от старших ARM процессоров вырезана тупым ржавым скальпелем, ещё не успело зарубцеваться
SVC_Handler - крутое прерывание пользователя из разряда - пусть весь мир подождёт
DebugMon_Handler - запуск кода отладчика на ядре мк в момент контрольной точки, остановка ядра после кода - для считывания данных отладчиком
пусто
PendSV_Handler - типа удобная функция для переключения контекста, я так не думаю
SysTick_Handler - самый примитивный таймер во всей системе, он даже не полностью 32 бита.

/* External Interrupts */
WWDG_IRQHandler - сторожевая собака, гавкает когда перестают ходить строем

[jeka]

jcxz, спасибо за ответ. В целом как и предполагал. И понизить приоритет чтоб завершить все подвисшие обработчики прерываний тоже полезная штука, о ней как раз думал.

Итог - кроме как через стек возврата не сделать. Вопрос решен.

AVI-crak, Да, MPU хорошо сделали. Главное просто и все что надо есть. Хотя еще не пробовал с ним работать.

[jcxz]

jcxz, спасибо за ответ. В целом как и предполагал. И понизить приоритет чтоб завершить все подвисшие обработчики прерываний тоже полезная штука, о ней как раз думал.

Да, забыл указать, что для описанного метода желательно править Process stack и возврат из этого ISR тогда будет идти в Thread mode.
Можно конечно и Main stack править, но тогда нужно перед возвратом из этого ISR сделать запрет прерываний и fault-ов.

[Forger]

Вот читаю, вижу интересные мудрёные решения, но вопрос остается прежний - чем не угодил традиционный System Reset с предварительным сохранением нужных данных в ОЗУ/FLASH/EEPROM?
Ведь рано или поздно излишняя самодеятельность с ручной правкой стека приведет к самым неожиданным последствиям в самый неожиданный момент ...
А если девайс еще и напрямую управляет опасной "силой", то я бы стопитсот раз подумал.
Имхо, лучше лишний раз "передернуть" все железо, чем так нагло влезать в стек подобного девайса

[AVI-crak]

Имхо, лучше лишний раз "передернуть" все железо, чем так нагло влезать в стек подобного девайса

Чтобы не ресетить девайс - нужно изначально закладывать архитектуру здоровой OS, с отдельным стеком прерываний и куче стеков задач. В этом случае запуск/отключение и управление уровнем прерывания - осуществляется через активную задачу, которая вызывает системное прерывание с заведомо максимальным уровнем.
Без блокировки!!!

Править уровни прерываний и их очереди в теле пользовательских прерываний - это есть громадный костыль, означающий что программист накосячил в нескольких местах и не смог исправить. Если прерывание пользователя зависает в бесконечном цикле - то лучше сразу сменить род деятельности, пока более опытные товарищи вам ноги руки не по отрывали.

Уход в глубокий сон выполняется по команде OS, после чего все активные задачи должны свернуть свою деятельность и уйти в зависимость, вот после этого можно сохранять на флеш - активную память задач и их стеки, с последующим отключением питания. Предусмотреть все ньюансы работы периферии - просто невозможно. Однако в самой активной задаче - вполне реально. Просто блок инициализации будет выполняться повторно при перезапуске в каждой задаче отдельно.

Глубокий сон - весьма специфическое требование, его трудно выполнить качественно, всегда придётся идти на компромисс. Гораздо чаще делают более простой вариант - сохраняют только данные объявленные как статические - в энергонезависимой памяти. С копированием их в память при запуске и сохранением перед отключением.

[Forger]

нужно изначально закладывать архитектуру здоровой OS, с отдельным стеком прерываний и куче стеков задач.

Ну, обычно существующие ОS под cortex именно так и реализованы
Но что-то мне подсказывает, что в данном случае OS вообще не используется ...

Править уровни прерываний и их очереди в теле пользовательских прерываний - это есть громадный костыль, означающий что программист накосячил в нескольких местах и не смог исправить. Если прерывание пользователя зависает в бесконечном цикле - то лучше сразу сменить род деятельности, пока более опытные товарищи вам ноги руки не по отрывали.

Вы прям озвучили мои мысли

[jeka]

Править уровни прерываний и их очереди в теле пользовательских прерываний - это есть громадный костыль, означающий что программист накосячил в нескольких местах и не смог исправить.

Никто уровни и очереди не правит. Еще раз - задача выполнить reset, но не всего и сразу, а выборочный. Включая сброс NVIC. Чтобы часть периферии и данных в RAM остались нетронутыми.

Чтобы не ресетить девайс - нужно изначально закладывать архитектуру здоровой OS

Вы эту ОС будете переустанавливать/обновлять без ресета?
Действия при аварии электропитания тоже предполагаются без ресета?

[Forger]

Включая сброс NVIC.

NVIC является частью ядра, поэтому сбросить NVIC без сброса всего ядра никак не получится (оно и к лучшему).
Сбросить ядро (или весь МК) можно программно, но все МК делают это по-разному.
В частности, ST умеет делать полноценный аппаратный сброс (как будто дернули внешний NRST) программно через system reset .

[LightElf]

Чтобы часть периферии и данных в RAM остались нетронутыми.

Дык не трогайте данные в RAM - они и останутся нетронутыми. Ресет содержимое SRAM не затрагивает. Для пущей безопасности нужный кусок SRAM защитите CRC или еще каким образом.

[Forger]

Дык не трогайте данные в RAM - они и останутся нетронутыми. Ресет содержимое SRAM не затрагивает. Для пущей безопасности нужный кусок SRAM защитите CRC или еще каким образом.

Не прокатит - ТС не желает сбрасывать всю периферию
Я уже предлагал решить эту задачу, разбиением программы на т. н. "модули", тогда несложно сделать возможность выполнять полную переинициализацию каждого модуля индивидуально.
Практически всю периферию можно переинициализировать заново, нельзя тока нормально сбросить NVIC, т. к. NVIC является частью ядра.
Но NVIC тоже можно переинициализировать, пусть это и будет неким колхозом.

Я бы в данной задаче реализовал отложенный сброс каждого модуля индивидуально: модуль (задача/задачи), который нужно перезапустить, получает соотв. уведомление и решает сам, когда и как нужно делать сброс.
После чего модуль "сообщает", что это сброс был выполнен или это невозможно выполнить в данный момент.

Но все же лучше по-искать другое решение, которое в случае тотального алярма без проблем позволит сделать полноценный сброс всего проца )))

[jcxz]

Ресет содержимое SRAM не затрагивает.

Да ладно??! А код boot-ROM, выполняемый после сброса, где стек и рабочие переменные размещает?

[Forger]

Да ладно??! А код boot-ROM, выполняемый после сброса, где стек и рабочие переменные размещает?

В STM32 SRAM не страдает от сброса (кроме, разумеется, сброса от передергивания питания, после которого там всегда будет "мусор").
STM32 RAM behavior after soft-reset


зы Помню, что как-то давно я все недоумевал, зачем в STM32 есть boot-режим старта прямо из ОЗУ (соотв. ремап вектора сброса на начало ОЗУ)? ...

[jcxz]

В STM32 SRAM не страдает от сброса (кроме, разумеется, сброса от передергивания питания, после которого там всегда будет "мусор").

Да ладно?!! Они умудрились написать код чисто на регистрах и без использования стека??? Прямо чудеса чудесатые какие-то рассказываете.....
Или они стек boot-ROM-а научились размещать в облаке?

[Forger]

Да ладно?!! Они умудрились написать код чисто на регистрах и без использования стека??? Прямо чудеса чудесатые какие-то рассказываете.....

Вы ничего не путаете?

В STM32 есть два спец пина BOOT0 и BOOT1, оменно они определяют кто будет запускаться при старте проца:
user-код (User Flash memory), boot-загручик (System memory), ОЗУ или еще что-то (например, в "толстых" камнях).
Опрос этих пинов производится ядром (или узлом, который отвечает за выбор области загрузки) в течение нескольких тактов после сброса.
Но даже в случае безусловного использования бут-загручика можно выяснить области ОЗУ, которые он использует. А используют они совсем небольшую часть ОЗУ.
Это не секретная информация Все есть в соотв. мануалах ))

Еще раз: BOOT-загрузчик в STM32 НЕ стартует безусловно.
Более того, в тотально залоченном состоянии бут вообще невозможно запустить (разве что прочитать его версию):
When readout protection Level2 is activated, STM32 does not boot on system memory in
any case and Bootloader can't be executed (unless jumping to it from Flash user code, all
commands are not accessible except Get, GetID, and GetVersion).


Может, вы путаете STM32 с другими камнями (которые без своей FLASH), где BOOT стартует ВСЕГДА после сброса?

[jcxz]

Вы ничего не путаете?

В AN2606 в Table 66. STM32F42xxx/43xxx configuration in system memory boot mode указано, что 8 Kbyte starting from address 0x20000000 are used by the bootloader firmware.
И эта область указана как Common to all bootloaders.
Также видно, что указатель стека из вектора сброса из таблицы векторов прерываний в ROM по адресу 0x1FFF0000 (из STM32F429 который у меня сейчас на столе) указывает на адрес 0x20002318 опять-же - внутри этих 8КБ.
Вот именно этот код, который считывает BOOT-пины и определяет куда передать управление (и возможно что-то ещё делает), видимо и находится по адресу, на который указывает вектор сброса из 0x1FFF0000.

PS: Не посчитал однако... 0x20002318 - это ведь уже за пределами 8КБ. Странно....
Опять-же - в AN2606 говорится про Bootloader V7.x. А какая у моего версия - не знаю.

[Forger]

В AN2606 в Table 66. STM32F42xxx/43xxx configuration in system memory boot mode указано, что 8 Kbyte starting from address 0x20000000 are used by the bootloader firmware.
И эта область указана как Common to all bootloaders.
Также видно, что указатель стека из вектора сброса из таблицы векторов прерываний в ROM по адресу 0x1FFF0000 (из STM32F429 который у меня сейчас на столе) указывает на адрес 0x20002318 опять-же - внутри этих 8КБ.

Дык, я с этим и не спорю, в прошлом посте я дал ссылку на большой документ, где это написано.
Вот только это имеет отношение только для случая, если boot загручик был запущен.

Вот именно этот код, который считывает BOOT-пины и определяет куда передать управление (и возможно что-то ещё делает), видимо и находится по адресу, на который указывает вектор сброса из 0x1FFF0000.

Вы не понимате )))
Нету никакого кода, который якобы считывает эти два пина. Это все сделано аппаратно. И происходит это в первые 4 такта проца после сброса.
Это указано в мануале на каждый проц: The boot mode configuration is latched on the 4th rising edge of SYSCLK after a reset. It is up to the user to set boot mode configuration related to the required boot mode.
Даже если бы эти пины опрашивались в неком коде, то даже гипотетически невозможно создать такой код, который бы за 4 такта умудрился проинитить хотя бы стек, настроить пару пинов и прочитать их содержимое


Кстати, вот это только что выяснил: The boot mode configuration is also re-sampled when exiting from Standby mode, на будущее надо учесть!

[jcxz]

STM32 does not boot on system memory in any case and Bootloader can't be executed

boot / не-boot - вопрос не в том, что в конце-концов стартует, а в том - какая ОЗУ портится при старте.

[Forger]

boot / не-boot - вопрос не в том,

Вопрос был как раз именно "в том":

Да ладно?!! Они умудрились написать код чисто на регистрах и без использования стека??? Прямо чудеса чудесатые какие-то рассказываете.....

Чудес не бывает, но бывает недостаточно внимательное чтение мануалов

...а в том - какая ОЗУ портится при старте.

Дык, если сам user-код гадит под себя портит ОЗУ, то все вопросы к этому самому коду!
Но это РЕШАЕМО (способов несколько).

[jcxz]

Это указано в мануале на каждый проц: The boot mode configuration is latched on the 4th rising edge of SYSCLK after a reset. It is up to the user to set boot mode configuration related to the required boot mode.
Даже если бы эти пины опрашивались в неком коде, то даже гипотетически невозможно создать такой код, который бы за 4 такта умудрился проинитить хотя бы стек, настроить пару пинов и прочитать их содержимое

Содержимое этого пина может защёлкиваться аппаратно в какой-то регистр по сбросу (так сделано во многих МК), а вот после уже может быть код, который его оттуда считает и проанализирует. 4 такта тут не надо, значение пина уже защёлкнуто. А вот делать кучу других действий после этого по инициализации чего-нить или хотя-бы выбору куда передать управление - много проще делать программно, тем более когда процессор всё равно под боком имеется.

[Forger]

Содержимое этого пина может защёлкиваться аппаратно в какой-то регистр по сбросу (так сделано во многих МК), а вот после уже может быть код, который его оттуда считает и проанализирует. 4 такта тут не надо, значение пина уже защёлкнуто. А вот делать кучу других действий после этого по инициализации чего-нить или хотя-бы выбору куда передать управление - много проще делать программно, тем более когда процессор всё равно под боком имеется.

Вы не со мной спорите, а с мануалом от ST. Имхо, это бессмысленно

[jcxz]

Дык, если сам user-код гадит под себя портит ОЗУ, то все вопросы к этому самому коду!

Вопрос не про пользовательский код. А именно про boot-ROM. И в каких случаях и где он портит.

Вы не со мной спорите, а с мануалом от ST. Имхо, это бессмысленно

Я не спорю с мануалом. Выдержку из него я привёл выше. В которой указывается, что "8 Kbyte starting from address 0x20000000 are used by the bootloader firmware".
Как там написано, так и читаю. К тому же там сказано про бутлоадер версии v7, а какой у меня - не знаю.

[Forger]

Вопрос не про пользовательский код. А именно про boot-ROM. И в каких случаях и где он портит.

Если не разрешать запуск boot, то содержимое SRAM не пострадает.
Но какой смысл запускать принудительно бут код, если в проце уже зашита рабочая прога и ее не нужно обновлять средствами бут-загрузчика?

Выдержку из него я привёл выше. В которой указывается, что "8 Kbyte starting from address 0x20000000 are used by the bootloader firmware".

А вы остальное почитайте, в частности раздел "Boot configuration".
Ссылку на более полный документ я приводил выше. Там уже расписано про все возможные бут-загручики любых STM32.
В т.ч. указано, какую и где память использует, сколько времени нужно на старт и какие условия необходимы для запуска загрузчика.

Не пойму, к чему этот спор?






Вот еще кое-что полезно для себя нашел, может, тоже кому пригодится:

Empty check
On ХХХХХХ devices only, internal empty check flag is implemented to allow easy programming of the virgin devices by the boot loader. This flag is used when BOOT0 pin is defining Main Flash memory as the target boot space. When the flag is set, the device is considered as empty and System memory (boot loader) is selected instead of the Main Flash as a boot space to allow user to program the Flash memory.

Т. е. этот тот самый случай, когда бутзагрузчик запускается безусловно не взирая на состояние BOOT0.
Но все же одно условие для этого нужно выполнить - флэш должна быть полностью стерта

В одном из моих нынешних проектов это оказалось очень даже актуально, очень ...

Сорри за офф ))))

[LightElf]

Вопрос не про пользовательский код. А именно про boot-ROM. И в каких случаях и где он портит.

Предположим, что бут-код стартует всегда и выбор режима дальнейшей работы осуществляется программно (тем более что у STM32F042 это именно так). что мешает осуществить эту проверку без стека и переменных? Это же буквально десяток асмовых команд (кстати, латч ножек Boot на 4 такт sysclk какбэ намекает). В общем не буду толочь воду в ступе - на всех виденных мной STM32 содержимое SRAM полностью сохраняется при сбросе, если ножками/фьюзами выбрана загрузка из флеша.

Т. е. этот тот самый случай, когда бутзагрузчик запускается безусловно не взирая на состояние BOOT0.
Но все же одно условие для этого нужно выполнить - флэш должна быть полностью стерта

Достаточно стертого вектора reset

Сообщение отредактировал LightElf - Aug 3 2017, 09:31

[Forger]

Предположим, что бут-код стартует всегда и выбор режима дальнейшей работы осуществляется программно (тем более что у STM32F042 это именно так).

Предполагать бессмысленно, все факты описаны в даташитах - выбор места старта выбирается неким аппаратным узлом, который НЕ является частью заводского бутзагрузчика.
Это по сути простейший автомат состояний, который размещен прямо на кристалле, он совсем крохотный, поэтому встроен в каждый STM, отключить его нельзя (а смысл?).
Он лишь, так сказать, "корректирует" вектор сброса перед запуском ядра.

В общем не буду толочь воду в ступе - на всех виденных мной STM32 содержимое SRAM полностью сохраняется при сбросе, если ножками/фьюзами выбрана загрузка из флеша.

Именно!
Более того, в SRAM судя по всему нет аппаратного сброса, поскольку, судя по даташитам, после подачи питания там "мусор".

Достаточно стертого вектора reset

Есть такое, вот тут нашел подтверждение:

Empty check (category 1 devices only)
On category 1 devices, an internal empty check flag is implemented to allow easy
programming of virgin devices by the bootloader. This flag is used when BOOT0 pin is
configured to select Flash program memory as target boot area. When this flag is set, the
device is considered as unprogrammed and the system memory (bootloader) is selected as
boot area instead of the Flash program memory to allow the application to program the
Flash memory.
The empty check flag is updated only when the option bytes are loaded: it is set when the
content of address 0x8000 0000 is read as 0x0000 0000 and cleared otherwise. As a result,
only a power-on reset or setting OBL_LAUNCH bit in FLASH_CR register can clear this flag
after programming a virgin device to execute user code after system reset.

Но этот флажок реализован не во всех STM32, в "старых" семействах, увы, он не реализован ((

[AVI-crak]

Режим отладки в памяти.
Программа в флеш выполняет две функции: запись адреса стека (аппаратная команда), меняет адрес массива векторов прерываний (аппаратный переход на ресет), повторный переход на новый ресет в памяти мк.
При физическом нажатии ресета - память sram не искажается.

Запуск кода из допустимых для данного мк областей памяти - память sram не искажается.
Ресет не искажает память.

Запуск бута в режиме программирования (после успешной синхронизации!!!) - всегда портит stam и стирает флеш при включённой защите (сразу!!!), стирает сам флеш по секторам при программировании (последовательно).
Без успешной синхронизации - содержимое памяти не искажается при ресете.

Бут является аппаратным механизмом, без использования ресурсов ядра и памяти. Но в момент полноценной работы - память stam используется в качестве буфера. Адреса массивов являются аппаратными, изменить их нельзя. Максимальный бардак в памяти получается при загрузке через usb.

Вас не должно волновать содержимое памяти после срабатывания бута - к этому моменту у вас уже поменялась прошивка.

[LightElf]

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

Действительно, бессмысленно предполагать. Надо тупо залезть дизасмом в бут и посмотреть

[Forger]

Надо тупо залезть дизасмом в бут и посмотреть

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

[AVI-crak]

Действительно, бессмысленно предполагать. Надо тупо залезть дизасмом в бут и посмотреть

КАК?
Каким образом смотреть содержимое ядра и адресного пространства мк в режиме явного срабатывания загрузчика по usart???
Вопрос на миллион баксов!!!

[Forger]

Каким образом смотреть содержимое ядра и адресного пространства мк в режиме явного срабатывания загрузчика по usart???

Вероятно, имелось ввиду подключиться отладчиком, и смотреть из-под соотв. проги, например, такой: https://www.segger.com/products/debug-probe...er/about-ozone/.
Это вполне реализуемо, если камень не залочен.

[jcxz]

Каким образом смотреть содержимое ядра и адресного пространства мк в режиме явного срабатывания загрузчика по usart???
Вопрос на миллион баксов!!!

Очевидно: подключиться стандартно эмулятором и с помощью него запустить код UART-загрузчика из ROM?
Или что имелось в виду?

[AVI-crak]

Или что имелось в виду?

Я говорю о том, что в момент аппаратного срабатывания триггера выбора загрузочного интерфейса - всё остальное отключается!!!!. Потому как сам механизм записи в память флеша - не имеет арбитра. Да и всего остального фарша - тоже.

[LightElf]

Каким образом смотреть содержимое ядра и адресного пространства мк в режиме явного срабатывания загрузчика по usart???
Вопрос на миллион баксов!!!

Не понял вопроса. Код бутлодера доступен для чтения всегда (если камень не залочен).

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

В даташите нигде не сказано, что выбор режима загрузки осуществляется строго аппаратно. На мой взгляд - это нелогично.

[Forger]

В даташите нигде не сказано, что выбор режима загрузки осуществляется строго аппаратно.

Явно слова hardware там не указано, но вы внимательнее почитайте про принцип выбора вектора сброса.
Более того, в даташитах явно указано, после выхода из standby режима повторно производится опрос пинов boot (это указано в даташитах), а уж это явно сделано аппаратно.
Ну, и как минимум то, что управление передается заводскому загрузчику по точно такому же принципу, как и юзер-коду,
наводит на мысль, что выбор вектора сброса производится где-то в недрах камня, про детальную работу которого нигде нет информации.
Если вам удастся найти эту информацию, поделитесь с нами

На мой взгляд - это нелогично.

Это еще почему?
По-мне - как раз существующее исполнение вполне логично.

[jcxz]

Я говорю о том, что в момент аппаратного срабатывания триггера выбора загрузочного интерфейса - всё остальное отключается!!!!.

Так всё-таки: что мешает не срабатывать этот самый триггер, а подключиться как обычно JTAG-ом, найти точку входа в процедуру загрузки по UART (в ROM очевидно) и запустить её ручками?
Может быть конечно, что при подключении JTAG область ROM становится невидимой, но обычно она видна (в тех МК что я видел).

[Forger]

Может быть конечно, что при подключении JTAG область ROM становится невидимой, но обычно она видна (в тех МК что я видел).

Если камень не залочен, то ВСЕ прекрасно видно, весь камень ))




зы Ради спортивного интереса прям щас принудительно кинул BOOT0 на VDD, подключился через Ozone. Загрузчик тут начинается с 0x1FFFC800 (discovery на базе STM32F072RB, st-link ессно перешит в j-link)
Встроенный бут запускается сразу же после сброса (нажали на кнопку, которая коротит NRST на землю) и тут же останавливается (нужно выбрать режим сброса "Reset & halt").
Т. е. управление СРАЗУ ЖЕ передается в System memory, как и указано в даташите.
Вот картинку сделал:



Кстати, посмотрел на состояние SRAMдо и после аппаратного сброса: не потерлась.
Кроме, конечно тех частей, к которым обращается сам код.

[jcxz]

Встроенный бут запускается сразу же после сброса (нажали на кнопку, которая коротит NRST на землю) и тут же останавливается (нужно выбрать режим сброса "Reset & halt").

Теперь осталось только обещанный миллион с AVI-crak стрясти! Все свидетели - он обещал

[AVI-crak]

зы Ради спортивного интереса прям щас

Дык это программный ресет, при аппаратном ресете отладчик не успевает подключиться, по крайней мере у меня.

[Forger]

Дык это программный ресет, при аппаратном ресете отладчик не успевает подключиться, по крайней мере у меня.

Нет, это - не "программный" ресет, это - сброс всего ядра и вообще всего проца (через модуль отладки).
Кстати, программный сброс у STM сделан так, что формирует фактически как и аппаратый сброс (тянет ножку NRST на землю на несколько мкс).
Отличается программный сброс у STM от полного сброса POR (подали питание) разве лишь тем, что содержимое SRAM сохраняется.
Открывайте мануалы, изучайте. Там все про это расписано. Внимательно читайте. Пусть у ST и не самая лучшая документация, но это там точно описано.

Я же пробовал под отладчиком жать аппаратный сброс (я написал об этом в прошлом посте, читайте внимательнее).
Поведение точно такое же, разве что отладчик подключается лишь сразу после отпускания кнопки сброс.
Но если выбрать режим подключения "Reset & Halt", то проц останавливается сразу же на месте запуска встроенного загрузчика или юзер софта (зависит от BOOT0).

Короче, если вы ВЕРИТЕ в существование какого-то мифического бут-загрузчика в STM, который всегда безусловано запускается, то это - лично ваше дело, вероисповедание - личное дело каждого.
Но коли речь идет про конкретные физические вещи, созданные обычными людьми, то и правила тут работают соответствующие - факты. Факты я привел.
А домыслы и мифы предлагаю оставить вне этой темы

[LightElf]

Это еще почему?
По-мне - как раз существующее исполнение вполне логично.

Городить аппаратный блок, уникальный для каждого кристалла и для дальнейшей работы совершенно не нужный, вместо того чтобы добавить пяток команд - это логично?

[Forger]

Городить аппаратный блок, уникальный для каждого кристалла и для дальнейшей работы совершенно не нужный, вместо того чтобы добавить пяток команд - это логично?

Этот вопрос сразу задавайте в ST. Ваши рекомендации им явно будут очень полезны

Мне же лично решение ST в данном случае кажется вполне логичным.

Городить аппаратный блок, уникальный для каждого кристалла

Он одинаковый, а в новых кристаллах лишь дополняется небольшим, но очень полезным функционалом, связанным с особенностями конкретного семейства - RTFM

[jcxz]

Городить аппаратный блок, уникальный для каждого кристалла и для дальнейшей работы совершенно не нужный, вместо того чтобы добавить пяток команд - это логично?

Вот именно! Я об этом же и писал - совершенно нелогично. Когда под боком такое мощное ядро.
В ST не дураки сидят - зачем делать то, что можно не делать?
Скорее всего ST хитрит - скрыли этот код инициализации в недокументированную область.

[Forger]

Вот именно! Я об этом же и писал - совершенно нелогично. Когда под боком такое мощное ядро.

Этот аппаратный узел позволяет вообще не трогать ядро, ничего не трогать.
Т.е. ядро, периферия, тактовые генераторы и т.п. изначально вообще остановлены.
Причины могут быть разные - борьба за потребление, за надежность да и мало еще за что?!

Короче, не нравится решение ST? Нет проблем - рисуйте свой проц и делайте так, как душе угодно

Скорее всего ST хитрит - скрыли этот код инициализации в недокументированную область.

Уфология прям - зеленых человечков никто не видел, но они есть!

[jcxz]

Т.е. ядро, периферия, тактовые генераторы и т.п. изначально вообще остановлены.

Ядро/тактовые генераторы и пр. изначально не остановлены. Иначе пользовательское ПО вообще не могло бы запуститься.

Уфология прям - зеленых человечков никто не видел, но они есть!

Это всего лишь логика.
Если к примеру на плате Вашего устройства уже стоит МК и вдруг появляется дополнительная необходимость - при включении питания платы (МК) пискнуть в динамик. Вы поставите дополнительную FPGA, на которой будете реализовывать генератор? Или всё-таки задействуете одну из ног существующего МК и напишете простенький цикл в начале ПО?

[Forger]

Ядро/тактовые генераторы и пр. изначально не остановлены. Иначе пользовательское ПО вообще не могло бы запуститься.

В режим standby тактирование ядра отключено, но при выходе из этого режима производится повторный опрос входов BOOT, это описано в даташите.
Что говорит о том, что опрос пинов BOOT производится аппаратно, но не программно неким мифическим скрытым загрузчиком. Это факт.

Это всего лишь логика.

Это всего лишь демагогия. Факты в студию - факты!

[LightElf]

Очевидно: подключиться стандартно эмулятором и с помощью него запустить код UART-загрузчика из ROM?
Или что имелось в виду?

Имелось в виду слить дамп памяти встроенного бутлодера и дизассемблировать его. Дабы подтвердить/опровергнуть предположение о программном характере выбора пути загрузки.
Посмотрел бут F030 - обращений к регистру конфигурации не увидел. Указатель стека сразу же указывает в RAM, но вначале достаточно долго RAM не портится - идет куча действий строго на регистрах.

[Forger]

Дабы подтвердить/опровергнуть предположение о программном характере выбора пути загрузки.

Встроенный загрузчик STM (размещен в System Memory) не участвует в принятии решения кто будет работать, т.к. он сам является частью выбора.
Он запускается после принятия решения. Я лично в этом убедился, о чем выше написал и привел скриншот.

[LightElf]

Встроенный загрузчик STM (размещен в System Memory) не участвует в принятии решения кто будет работать, т.к. он сам является частью выбора.
Он запускается после принятия решения. Я лично в этом убедился, о чем выше написал и привел скриншот.

Знаете что самое смешное? Что вы скорее всего правы, но аргументация ваша никакой критики не выдерживает.
Ну что за бред: "не участвует в принятии решения кто будет работать, т.к. он сам является частью выбора"? Какая логическая конструкция запрещает выбирать, в том числе, и из себя?
Точка останова на первой команде, расположенной в масочном ПЗУ - тоже ничего особо не доказывает. Совсем не факт, что дебаговый модуль и используемые для отладки пины включены сразу.
Микроконтроллеров, у которых пины JTAG настраиваются встроенным загрузчиком, чуть менее чем дофига.

[Forger]

Знаете что самое смешное? Что вы скорее всего правы,

Не вижу ничего смешного при работе с фактами, которые описаны в даташитах!

но аргументация ваша никакой критики не выдерживает.

Коли я прав, но моя аргументация вам не нравиться, так приведите свою, основанную на фактах, а не на домыслах и предположениях.

Точка останова на первой команде, расположенной в масочном ПЗУ - тоже ничего особо не доказывает.

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

Совсем не факт, что дебаговый модуль и используемые для отладки пины включены сразу.

Факт - пины JTAG доступны лишь при разлоченном проце (Level 1 или Level 0). В режиме Level 2 отладка навсегда заблокирована, снять блокировку нельзя.
Факт - на тотально залоченном проце (Level 2) бут-загрузчик при старте НИКОГДА НЕ запускается, о чем указано в датишите.
Факт из даташита (цитирую еще раз):
When readout protection Level2 is activated, STM32 does not boot on system memory in any case and
Bootloader can't be executed (unless jumping to it from Flash user code, all commands are not accessible except Get, GetID, and GetVersion).
Это говорит о том, что узел, определяющий кто может работать а кто нет - вначале ориентируется на Option Bytes и состояние пинов BOOT.
Не так уж и сложно сделать железобетонный автомат на логике, который все это делает без всяких микропрограмм и скрытых бут-загручиков.
Впрочем, как именно это сделано, нигде не описано. А причины просты - дабы не открыть секретную информацию по тому, как вскрыть залоченный проц.

Факт: в даташите указано, что запускается ИЛИ system memory со своим бутзагрузчиком ИЛИ flash memory с вашей прошивкой. ИЛИ/ИЛИ. Никаких других вариантов не указано.
Факт: загрузчик из System Memory запускается безусловно только в случае полностью стертого проца и то не в самых старых семействах ST.
В всех остальных случаях перед запуском бут-загрузчика производится анализ состояния пинов BOOT и в некоторых STM определенных регистров из Option области.

Обратите внимание, я привел факты.

Микроконтроллеров, у которых пины JTAG настраиваются встроенным загрузчиком, чуть менее чем дофига.

Мы говорим про конкретное семейство МК - STM32. Предлагаю не отвлекаться.

Короче, если найдете хоть какую-то новую информацию по работе узла запуска/загрузки STM, выкладывайте сюда. Со ссылками.

[LightElf]

Не вижу ничего смешного при работе с фактами, которые описаны в даташитах!

Ошибкой является принимать свою трактовку расплывчатых слова из даташита за факты.
Ну и вообще, даташиты очень часто многое умалчивают. Например даташит на STM32F101 умалчивает о наличии в на кристалле USB Device контроллера и нескольких лишних десятков килобайт FLASH.

Коли я прав, но моя аргументация вам не нравиться, так приведите свою, основанную на фактах, а не на домыслах и предположениях.

Да, мне не нравится отсутствие логики на техническом форуме.
В даташите описано конечное поведение микроконтроллера, а не способ реализации такого поведения. Наличие некой аппаратной схемы, которая там чего-то куда-то переключает в зависимости от состояния ножек и option bytes - это сугубо ваши домыслы, в даташите же ничего на эту тему не сказано.

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

Религию себе придумали вы и как раз вы и пытаетесь распространять свою веру, причем довольно агрессивно и напористо. Я же, всего-лишь навсего, утверждаю что в даташите вообще нет никакой информации о том, как именно обсуждаемый функционал реализован.

Факт - пины JTAG доступны лишь при разлоченном проце (Level 1 или Level 0). В режиме Level 2 отладка навсегда заблокирована, снять блокировку нельзя.
Факт - на тотально залоченном проце (Level 2) бут-загрузчик при старте НИКОГДА НЕ запускается, о чем указано в датишите.

В даташите указано, что к залоченному чипу нельзя достучаться снаружи через интерфейс загрузчика или отладочный порт. Все. Чего там внутри запускается или не запускается - не описано.

Факт из даташита (цитирую еще раз):
When readout protection Level2 is activated, STM32 does not boot on system memory in any case and
Bootloader can't be executed (unless jumping to it from Flash user code, all commands are not accessible except Get, GetID, and GetVersion).
Это говорит о том, что узел, определяющий кто может работать а кто нет - вначале ориентируется на Option Bytes и состояние пинов BOOT.

Это не говорит абсолютно ни о чем.

Не так уж и сложно сделать железобетонный автомат на логике, который все это делает без всяких микропрограмм и скрытых бут-загручиков.

Не сложно, главное верить.

Факт: в даташите указано, что запускается ИЛИ system memory со своим бутзагрузчиком ИЛИ flash memory с вашей прошивкой. ИЛИ/ИЛИ. Никаких других вариантов не указано.

А что, возможен вариант И/И? Ну и зачем производителю расписывать свою внутреннюю кухню, если потребителю от этого не холодно и не жарко?

Факт: загрузчик из System Memory запускается безусловно только в случае полностью стертого проца и то не в самых старых семействах ST.

Неправда, причем в данном случае прямо противоречащая даташиту. Вполне определенно сказано, что проверяется адрес 0x08000000 на равенство 0xFFFFFFFF.

Обратите внимание, я привел факты.

Нет. Вы привели цитаты из даташита и придумали им свои трактовки.

Короче, если найдете хоть какую-то новую информацию по работе узла запуска/загрузки STM, выкладывайте сюда. Со ссылками.

Щаз, штаны подтяну и ломанусь искать опровержения вашим выдумкам.

[Forger]

А что, возможен вариант И/И?

В фантастических книжках, конечно, возможен, но в реальности (в т. ч. в даташитах) пока что только ИЛИ

Если вы утверждаете, что загрузчик из System Memory стартует всегда и безусловно, несмотря на то, что в даташитах указано обратное,
то объясните эту цитату, которая есть в полном даташите на любой STM:

The boot mode configuration is also re-sampled when exiting from Standby mode.
Consequently they must be kept in the required Boot mode configuration in Standby mode.

Или вы веруете считаете, что во всех STM существует некий "секретный бут-загрузчик", который нигде не описан и который не имеет никакого отношения к официальному загрузчику из System Memory?
Я правильно понял?

[LightElf]

Если вы утверждаете, что загрузчик из System Memory стартует всегда и безусловно, несмотря на то, что в даташитах указано обратное,

И где же там указано "обратное"?

то объясните эту цитату, которая есть в полном даташите на любой STM:

А что именно вызывает затруднения в понимании? При выходе из Standby фактически происходит полная реинициализация процессора (кроме Backup домена). Видимо при этом отрабатывается ровно та же процедура, что и при PowerOn.

Или вы веруете считаете, что во всех STM существует некий "секретный бут-загрузчик", который нигде не описан и который не имеет никакого отношения к официальному загрузчику из System Memory?
Я правильно понял?

Конечно вы поняли неправильно, для чего вам потребовались значительные усилия.
Повторяю в третий раз:
в даташите абсолютно ничего не сказано про то, как именно реализован выбор варианта загрузки, описан только результат. Ваша святая вера в "секретную схему" ни на чем не основана.

На закуску читаем RM0090:

To select boot from Flash memory bank 2, set the BFB2 bit in the user option bytes. When
this bit is set and the boot pins are in the boot from main Flash memory configuration, the
device boots from system memory, and the boot loader jumps to execute the user
application programmed in Flash memory bank 2.

[Forger]

И где же там указано "обратное"?

Мля, да в любом полном даташите на ЛЮБОЙ STM32 в соотв. табличке указаны варианты исключительно ИЛИ:

в даташите абсолютно ничего не сказано про то, как именно реализован выбор варианта загрузки, описан только результат.

Я лично убедился под внешним сторонним отладчиком, что при конфигурации старта из System Memory, запускается системный бут-загрузчик строго с того адреса, где он указан в даташите.
Если же запускается некий "секретный загрузчик" до передачи управления в System Memory или Main Flash, то он не имеет никакого отношения к УСЛОВНО запускаемому загрузчику из System Memory.

Ваша святая вера в "секретную схему" ни на чем не основана.

Разумеется, можно верить в некий скрытый загрузчик, или как я - в более простое аппаратное решение, встроенное в камень.
Но, в данном случае это уже не имеет значения - информация об этом скрыта от нас судя по всему намеренно. Оттуда и домыслы.

Однако, как я понял, вы упорно верите в то, что загрузчик из System Memory стартует ВСЕГДА БЕЗУСЛОВНО несмотря на то, что в даташитах указан его УСЛОВНЫЙ старт .
А коли так, то предлагаю на этом поставить точку, ибо иначе это все, просто, перерастет в некую фантастику, религию и т. п.

[LightElf]

Мля, да в любом полном даташите на ЛЮБОЙ STM32 в соотв. табличке указаны варианты исключительно ИЛИ:

Я из этой таблички делаю вывод, что управление будет, в конце концов, передано в системный загрузчик или в пользовательскую прошивку - что мы собственно и наблюдаем вживую. Передано ли туда сразу (первой исполняемой командой процессора) или по результату исполнения некоего первоначального кода - из таблички никак не следует и уверенно сказать об этом нельзя.

Я лично убедился под внешним сторонним отладчиком, что при конфигурации старта из System Memory, запускается системный бут-загрузчик строго с того адреса, где он указан в даташите.
Если же запускается некий "секретный загрузчик" до передачи управления в System Memory или Main Flash, то он не имеет никакого отношения к УСЛОВНО запускаемому загрузчику из System Memory.

Я убедился путем дизассемблирования, что в STM32F030 в системной памяти нет команд, определяющих вариант загрузки. Но:
1) "секретный загрузчик" может быть и в другом месте
2) В других камнях STM32 может быть по-другому. Как минимум у STM32F042 отличия должны быть.

Разумеется, можно верить в некий скрытый загрузчик, или как я - в более простое аппаратное решение, встроенное в камень.
Но, в данном случае это уже не имеет значения - информация об этом скрыта от нас судя по всему намеренно. Оттуда и домыслы.

Это не вопрос веры, это вопрос неверия. У нас нет достоверной информации о том как это реализовано. Может быть так, может быть эдак, может быть еще каким-то третим способом. Но вы упорно настаиваете на одном конкретном варианте, непонятно на каком основании. Аппаратное решение совсем не проще в реализации и уж явно не гибче. Ежели какая-нибудь бага обнаруживается, то проще изменить заливаемый на конвейере код загрузчика, чем вносить изменения в маски.

Однако, как я понял, вы упорно верите в то, что загрузчик из System Memory стартует ВСЕГДА БЕЗУСЛОВНО несмотря на то, что в даташитах указан его УСЛОВНЫЙ старт .
А коли так, то предлагаю на этом поставить точку, ибо иначе это все, просто, перерастет в некую фантастику, религию и т. п.

Я уверен (и Reference Manual на STM32F4xx это подтверждает), что как минимум у ряда контроллеров из семейства STM32 код системной области (не буду называть его загрузчиком дабы избежать путаницы) принимает участие в выборе режима старта.

[Forger]

что мы собственно и наблюдаем вживую.

Алилуйя! Наконец-то мои слова услышаны!
Камень ведет себя именно так, как описано в даташите. Встроенный загрузчик запускается точно также условно, равно как и пользовательский код.
А вы пытались с этим спорить... Смысл?

Я убедился путем дизассемблирования, что в STM32F030 в системной памяти нет команд, определяющих вариант загрузки.

Ура!

1) "секретный загрузчик" может быть и в другом месте

Точно также он может быть лишь в фантазиях того, кто его выдумал

У нас нет достоверной информации о том как это реализовано. Может быть так, может быть эдак, может быть еще каким-то третим способом.

Вот, вы меня уже цитируете

Но вы упорно настаиваете на одном конкретном варианте, непонятно на каком основании.

Читайте внимательнее:
Я настаиваю совсем на другом - чтобы вы не путали встроенный штатный бутзагрузчик с неким своим вымышленным "секретным" загрузчиком.

Аппаратное решение совсем не проще в реализации и уж явно не гибче. Ежели какая-нибудь бага обнаруживается, то проще изменить заливаемый на конвейере код загрузчика, чем вносить изменения в маски.

Весьма спорное утверждение - камни на заводе не прошивают, как вам это может показаться. Тестируют кристаллы прямо на пластине, причем, наверняка выборочно.
Бут-загрузчик у STM находится не во FLASH, а в некой ROM, она обходится дешевле FLASH.
Эта ROM не прошивается, а формируется сразу на этапе производства масок для процессов литографии и т. п.
Т.е. для смены версии загрузчика меняется целиком весь кристалл заодно с исправлениями ядра/периферии, а отдельно перешивать уже изготовленные камни никто не будет - это абсолютно невыгодно.

Для примера - если в печатной плате есть некритичный косяк, то такие косяки "накапливают" с другими и выпускают новую версию платы, где эти косяки исправлены ВСЕ ВМЕСТЕ.
Никто не будет по-настоящему серийные платы вручную дорабатывать, т. к. их намного выгоднее списать и сделать новые правильные.
А в случае микросхем зачастую выгоднее выпустить еррату и "собирать косяки" на новую версию камню. Чем толще еррата, тем более скупой производитель процов
Не стоит путать реально мега-массовое про-во со штучными "гаражными" поделками!

Я уверен (и Reference Manual на STM32F4xx это подтверждает), что как минимум у ряда контроллеров из семейства STM32 код системной области (не буду называть его загрузчиком дабы избежать путаницы) принимает участие в выборе режима старта.

Дык, если это указано в даташите на этот камень, то так одно и должно быть. Уверен, что под отладчиком это будет полностью подтверждено. Я с этим не спорил и не спорю ))
Речь-то совсем о другом - о том, что не описано ни в одном официальном даташите и никак не выясняется под отладчиком.
Этот "аппаратный узел" / "секретный загручик" не имеет никакого отношения к штатному загрузчику из System memory, он не является его частью, что подтверждают даташиты и отладчик.
С самого начала именно это я и пытался донести.
Теперь-то, надеюсь, все прояснилось?

[LightElf]

Камень ведет себя именно так, как описано в даташите. Встроенный загрузчик запускается точно также условно, равно как и пользовательский код.
А вы пытались с этим спорить... Смысл?

Итоговое поведение процессора соответствует даташиту. Как именно это реализовано - по-прежнему неизвестно.

Читайте внимательнее:
Я настаиваю совсем на другом - чтобы вы не путали встроенный штатный бутзагрузчик с неким своим вымышленным "секретным" загрузчиком.

Читайте внимательнее: у STM32F42x это один блок кода.

Весьма спорное утверждение - камни на заводе не прошивают, как вам это может показаться. Тестируют кристаллы прямо на пластине, причем, наверняка выборочно.
Бут-загрузчик у STM находится не во FLASH, а в некой ROM, она обходится дешевле FLASH.
Эта ROM не прошивается, а формируется сразу на этапе производства масок для процессов литографии и т. п.
Т.е. для смены версии загрузчика меняется целиком весь кристалл заодно с исправлениями ядра/периферии, а отдельно перешивать уже изготовленные камни никто не будет - это абсолютно невыгодно.

К счастью, в ST идиотов мало сидят достаточно умные люди, чтобы не пытаться вышеуказанную чушь реализовывать. Потому бутлоадер размещают в самом обычном флеше и прошивают его в процессе производства. Что позволяет не только менять заливаемую версию бутлодера без изменения масок, но и складывать туда Unique ID, калибровки температурного датчика и тактового генератора, уникальные для каждого кристалла. О чем, совершенно не скрываясь, пишут в своих даташитах.

To improve the accuracy of the temperature sensor (especially for absolute temperature
measurement), calibration values are individually measured for each part by ST during
production test and stored in the system memory area.

Маску наверно под каждый кристалл переделывают, угу.

Для примера - если в печатной плате есть некритичный косяк, то такие косяки "накапливают" с другими и выпускают новую версию платы, где эти косяки исправлены ВСЕ ВМЕСТЕ.
Никто не будет по-настоящему серийные платы вручную дорабатывать, т. к. их намного выгоднее списать и сделать новые правильные.

Смотря что за платы и что за доработки. Иногда значительно дешевле доработать. Тому куча примеров как в весьма серьезном оборудовании, так и в китайском ширпотребе.

А в случае микросхем зачастую выгоднее выпустить еррату и "собирать косяки" на новую версию камню. Чем толще еррата, тем более скупой производитель процов
Не стоит путать реально мега-массовое про-во со штучными "гаражными" поделками!

Вы специалист по мега-массовому производству или из гаража разъяснения даете? Сколько миллионов изделий произвели?

Дык, если это указано в даташите на этот камень, то так одно и должно быть. Уверен, что под отладчиком это будет полностью подтверждено. Я с этим не спорил и не спорю ))
Речь-то совсем о другом - о том, что не описано ни в одном официальном даташите и никак не выясняется под отладчиком.

Учебник логики купите. Может поймете, чем "отсутствие доказательства явления" отличается от "доказательства отсутствия явления".

Сообщение отредактировал LightElf - Aug 30 2017, 08:41

[Forger]

Вы специалист по мега-массовому производству или из гаража разъяснения даете? Сколько миллионов изделий произвели?

Учебник логики купите. ....

Поскольку диалог перешел на личности (т.е. закончились разумные аргументы), то не вижу никакого смысла продолжать его дальше.

[LightElf]

Поскольку диалог перешел на личности (т.е. закончились разумные аргументы), то не вижу никакого смысла продолжать его дальше.

Рекомендация почитать учебник - переход на личности? Как все запущено.

Ну и так, чтобы черту подвести. Берем дамп системной области STM32F042F4, смотрим чего там и как. И видим такую замечательную последовательность команд:

1FFFCAA0 MOVS R0, #0x8000000
1FFFCAA4 LDR R1, [R0]
1FFFCAA6 ADDS R1, R1, #1
1FFFCAA8 BEQ loc_1FFFCAD4

И далее:

1FFFCAB2 LDR R2, =0x40010000
1FFFCAB4 MOVS R1, #0
1FFFCAB6 STR R1, [R2]

Комментарии нужны или и так понятно?

[Forger]

И видим такую замечательную последовательность команд:

Именно - © "Как все запущено": в штатном загрузчике есть команда GO, выполняется по запросу по каналу обмена, из которого шла заливка свежей прошивки.
Вы привели кусок этой команды, выдранный из штатного загрузчика, который без труда можно вычитать. С этим справится любой школьник.
Повторюсь: штатный загрузчик не имеет никакого отношения к некому скрытому аппаратному узлу (или по-вашему некому секретному загрузчику), который определяет порядок запуска кода.

Короче, есть что-нибудь дельное, по теме?