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

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

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

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

Вот такие мысли...


А то что при отладке через жетаг для правильного хождения по командам надо иметь уровень оптимизации 0, а для работы повыше? Вас не парит все время через опшинсы руками переставлять?
А отладка в порт с кучей сообщений и режимом только ошибок переключать, не забывая дефайны пробивать?

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

переключил, и куча флажков и настроек встали одним движением в нормальное состояние...

2 Golikov A.
А как это, задать бит во флэш? Целый сектор памяти стирать-программировать...
Таргеты - да, здорово расписали. Опции компилятора переключить мне не сложно, отладкой по ком-порту не пользуюсь, а вот дефайны - да, их же можно задать в свойствах проекта! Правда, отладочных дефайнов у меня с десяток...

Это еще зачем?? Всегда выставлял Full optimization под IAR. Зачем чего-то отлаживать на том уровне, который все-равно не будет в релизе?? По первости делал без оптимизации, вроде все работает, потом выставляю фулл - и "привет", висим и все тут...

тут да, потеря 1 сектора из начальных маленьких...


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


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

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

Да вот по чем зря, бывает, элементарно, не поставил volatile у какой-нить переменной и все! В нуле-то работает и не жужжит, а в фулл никак...



Ну да, я так вообще никогда не делаю, это одно дело, IPстек или графическую библиотеку портировать, но весь проект - это уже больно поGNUшнински получается - или по-русски "черт ногу сломит"

что Вы имеете в виду под программным сбросом ?
у меня, например, LPC1769 (суть не в камне, а в подходе) - в регистре источника сброса 4 флага: power-on reset, external reset, WDT reset, BOD reset
могу ли я читая другой регистр понять, что сброс был программный ?

если передавать флаг программного сброса через озу (например, совместно с WDT reset), то описано ли в каком нибудь документе то, что содержимое озу не портится во время reset ?

И если ни один из них не установлен, тогда какой был сброс?

спасибо. попробую и перепишу bootloader.

вопрос с передачей флага "нужно прошиваться" через SRAM актуален

Таких документов много. Но сама программа, как правило прежде чем дойдет до main()
установит озу в нужное состояние. Чтобы этого не было, в IAR, например надо добавлять __no_init
перед обьявлением переменной.

Наверное, не написано, но это и так все знают
Нужно очень постараться, чтобы затереть статическое ОЗУ одномоментно, не снимая питание.

Ну сами подумайте, у статики нет инициализации и тактировки, как у динамики, затереть ее может только сама программа, да и то, если не используете монитор питания.

а как при старте инициализируемые 0 переменные становятся нулевыми? Сброс то у памяти может и быть, а его могу и дергать.

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

Оч. смешно. Цикл зануляет соответствующие ячейки памяти, если вы ещё не в курсе.


Примеры - в студию! Это будет открытие века!

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

Достаточно весело. У вас в main есть такой цикл? Это я к тому что советуя передать переменную через память сквозь ресет, надо еще уточнить где и что задушить, чтобы человек не бился с 0 переменной как рыба об лед.


как-то свой проц сделал на FPGA, у него был сброс. Такой пример пойдет? я совершил открытие?


жаль....