[Forger 17]

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

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

Годится такое решение?

[jeka 0]

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

[Forger 17]

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

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

 

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

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

[jeka 0]

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

[Forger 17]

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

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

[jeka 0]

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

[KSN 0]

По поводу непрерывного протокола обмена.

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

Работает так: прилетает команда по интерфейсу "перейти в bootloder". Application отвечает, что команда принята, выполняет необходимы действия, устанавливает переменную и вызов bootloader. Bootloader "понимает" что был переход по команде, шлет по интерфейсу подтверждение исполнения команды и далее обрабатываются команды для bootloadera. После завершения обновления прошивки, приходит команда "выйти из bootloader" - посылается ответ, что команда принята, устанавливается переменная, выполняются необходимые действия и переход в Application. Application "понимает", что был выход из bootloadera по команде, шлет "подтверждение исполнения" команды и продолжает исполняться код приложения.

[jcxz 184]

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

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

 

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

Не понял... %-\ Зачем???

Вам же надо вроде только разрешить некое другое прерывание, причём тут возврат из текущего?

[Forger 17]

По поводу непрерывного протокола обмена.

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

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

Есть защита от подобных сбоев?

[jcxz 184]

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

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

 

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

Почему "колхоз"?

Такой "колхоз" даже производители некоторых МК делают Например в Infineon, после передачи управления пользовательскому ПО из ROM-загрузчика, в начале ОЗУ гарантируется наличие некоторых данных (например - серийный номер чипа).

И в Вашем случае, для передачи неких команд управления вашему бутлоадеру вполне можно также делать. Но опять-же - с умом.

Например:

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

[KSN 0]

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

Есть защита от подобных сбоев?

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

[Obam 30]

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

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

 

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

[jeka 0]

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

[Obam 30]

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

[jeka 0]

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

 

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