Forger 24 12 июля, 2017 Опубликовано 12 июля, 2017 · Жалоба Специфика такая. Не хочется протокол обмена обрывать, т.к. это вызывает проблемы на главном устройстве, а их решить сложнее чем протокол поддерживать. А если сохранить параметры протокола в энергонезависимой памяти, а после сброса (даже аппаратного) восстановить их и продолжить с прерванного места? Годится такое решение? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jeka 0 12 июля, 2017 Опубликовано 12 июля, 2017 · Жалоба годится, но больно сложно получается. Плюс дополнительная блокировка обмена на этапе рукопожатия (пока трём и пишем страницу во flash) перед прошивкой может проблем добавить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 24 12 июля, 2017 Опубликовано 12 июля, 2017 · Жалоба годится, но больно сложно получается.Да неужели? Вот тут я бы поспорил, что сложнее ... :) Плюс дополнительная блокировка обмена на этапе рукопожатия (пока трём и пишем страницу во flash) перед прошивкой может проблем добавить. Обмен все равно придется прекратить на всё время обновления прошивки. Так в чем проблема приостановить обмен перед сохранение его параметров? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jeka 0 12 июля, 2017 Опубликовано 12 июля, 2017 · Жалоба Ну не хочется городить огород с записью во флеш, правкой дисциплины обмена когда есть простое и работающее без нареканий на других процессорах решение. Решение меня не устраивало только тем что не хотел вставлять ассемблерную функцию. Пока варианта лучше нет, будет так. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 24 12 июля, 2017 Опубликовано 12 июля, 2017 · Жалоба ... когда есть простое и работающее без нареканий на других процессорах решение. Но тогда с какой целью затевалась эта тема? ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jeka 0 12 июля, 2017 Опубликовано 12 июля, 2017 · Жалоба Цель - понять, можно ли на arm сбросить маскировку прерываний кроме как командой возврата из прерывания. Хочется без костыля в виде функции на ассемблере обойтись. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KSN 0 13 июля, 2017 Опубликовано 13 июля, 2017 · Жалоба По поводу непрерывного протокола обмена. Делаю так: в RAM есть структура, которая не инициализируется средствами компилятора при старте программы. Через эту структуру bootloader и application обмениваются информацией( вызов bootloadera из application, возврат из bootloader в application). Использую какие-нибудь хитрые значения для этих переменных, а не простые 0x00000000, 0xFFFFFFFF, наподобие значение переменных для снятие блокировки с watch-dog, flash memory в stm32f. Работает так: прилетает команда по интерфейсу "перейти в bootloder". Application отвечает, что команда принята, выполняет необходимы действия, устанавливает переменную и вызов bootloader. Bootloader "понимает" что был переход по команде, шлет по интерфейсу подтверждение исполнения команды и далее обрабатываются команды для bootloadera. После завершения обновления прошивки, приходит команда "выйти из bootloader" - посылается ответ, что команда принята, устанавливается переменная, выполняются необходимые действия и переход в Application. Application "понимает", что был выход из bootloadera по команде, шлет "подтверждение исполнения" команды и продолжает исполняться код приложения. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 13 июля, 2017 Опубликовано 13 июля, 2017 · Жалоба Назрела необходимость (уже давно), разрешить прерывания более низкого приоритета в обработчике высокого приоритета. А в чём проблема? Разрешаете через соотв. регистр NVIC и всё. У меня много где внутри одних ISR разрешаются/запрещаются другие. Способ в лоб - подкорректировав стек и сделать фиктивный возврат из прерывания. Не понял... %-\ Зачем??? Вам же надо вроде только разрешить некое другое прерывание, причём тут возврат из текущего? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 24 13 июля, 2017 Опубликовано 13 июля, 2017 · Жалоба По поводу непрерывного протокола обмена. Делаю так: в RAM есть структура, которая не инициализируется средствами компилятора при старте программы. Скажем, питание было выдернуто (передернуто) в процессе обмена данными через эту область ОЗУ и тем более в процессе заливки новой прошивки. Есть защита от подобных сбоев? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 13 июля, 2017 Опубликовано 13 июля, 2017 · Жалоба в документации написано что запись в IPSR игнорируется. Если с умом подходить, то и в IPSR можно записать. Только - зачем? Ей нужно по хорошему передать несколько параметров. Плюс как определить что на ребут для определенной цели ушел? В память записать определенную сигнатуру? Но это то же колхоз. Почему "колхоз"? Такой "колхоз" даже производители некоторых МК делают Например в Infineon, после передачи управления пользовательскому ПО из ROM-загрузчика, в начале ОЗУ гарантируется наличие некоторых данных (например - серийный номер чипа). И в Вашем случае, для передачи неких команд управления вашему бутлоадеру вполне можно также делать. Но опять-же - с умом. Например: Обычно в МК есть флажки, позволяющие определить причину сброса (внешний reset, POR, WDT, etc.). Так вот: после старта бутлоадер может посмотреть на флажки и, если там указан WDT, проверить некую область ОЗУ на наличие ключа. Если причина сброса - не WDT, то не читать ключ. Соответственно в рабочей прошивке, сразу после получения управления, в область ключа записывается НЕ_ключ и спокойно работаем. Если пришла необходимость сделать переход в бутлоадер: формируем WDI, пишем в область ключа собственно ключ и делаем сброс по WDT. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KSN 0 13 июля, 2017 Опубликовано 13 июля, 2017 · Жалоба Скажем, питание было выдернуто (передернуто) в процессе обмена данными через эту область ОЗУ и тем более в процессе заливки новой прошивки. Есть защита от подобных сбоев? Да, конечно. Проверка CRC прошивки, область bootloaderа защищена. При возникновение такой ситуации устройство перезагрузится, останется в bootloader, при этом по интерфейсу будет послано сообщение в систему. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Obam 38 13 июля, 2017 Опубликовано 13 июля, 2017 · Жалоба Назрела необходимость (уже давно), разрешить прерывания более низкого приоритета в обработчике высокого приоритета… Есть ли какое-то более человеческое решение чем через формирование стека возврата и возврат из прерывания? Как возможность, вызов прерывания с достаточным приоритетом записью его номера в STIR: ваш обработчик высокого приоритета отработает, и будет исполняться тот, что из STIR. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jeka 0 13 июля, 2017 Опубликовано 13 июля, 2017 · Жалоба Прошу прощения, не указал один важный момент, из-за которого путаница возникла: из обработчика прерывания высокого приоритета возврат не предполагается. Совсем. Предполагается не выходя из обработчика этого irq сделать фактически рестарт процессора и передачу управления нужному модулю с переинициализацией стека, контроллера прерываний и остальной периферии. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Obam 38 13 июля, 2017 Опубликовано 13 июля, 2017 · Жалоба Тогда вообще ни о чём: сброс и всё. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jeka 0 13 июля, 2017 Опубликовано 13 июля, 2017 · Жалоба Сброс не желателен, т.к. состояние части периферии нужно сохранить. Вообще топик не про поиск обходных путей решения (это мне не нужно - придумать с десяток вариантов и сделать один из вариантов проблем не составляет), а про конкретную аппаратную особенность процессора, а именно сброс текущего приоритета прерываний без шаманства со стеком. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться