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

Файл конфиг для IAR
Нажмите для просмотра прикрепленного файла

Прошивка с 0 адреса
Нажмите для просмотра прикрепленного файла

Прошивка с 0х8000 адреса
Нажмите для просмотра прикрепленного файла

Подскажите что я делаю не так?

Вы бы сами на файлы поглядели бы: неиспользованная память - заполнена FF

А чем ее нужно было заполнять?

Её, как раз, ничем заполнять не нужно
P.S. Скорее всего, в Вашем случае это заполнение вредно: заполненное кодом FF "перетирает" полезное содержимое другого файла... Слово "флешка" в первом посте - это ведь не flash-память программ Вашего МК?

Пересобрал прошивки без заполнителя. Результат тот же. При считывание памяти МК неиспользуемая память все равно заполнена FF

Ага, значит записываете, всё-така в память программ... FF - это, нормально, стёртая память читается как FF
А у Вас начало памяти программ заполнено разными данными в обоих файлах!

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

Допустим начало памяти разное, сначала я записываю прошивку,которая начинается с 0х8000 адреса. потом записываю прошивку которая начинается с 0 адреса, по идеи хотя бы та что с нулевого должна же грузится. А у меня контроллер не подается признаков того что прошивка начинает работу

Каждый файл начинается с расположенной по адресу 0 команды перехода на начало программы: 0C94624B или 0C949551. Первые два байта - одинаковые, а вот адреса переходов - разные. при программировании в предварительно стёртой памяти (содержит FF) "прописываются" нолики, при записи второго файла - эти ячейки уже не будут содержать FF, но "добавятся" нолики из другого файла.
И, вообще, - не понятно: как вы собираетесь запускать программу из второй половины памяти? Вектора у Вас разделятся между программами как будут?

Это все равно не объясняет проблемы что не грузиться даже прошивка расположенная в начале памяти. Ведь получается все данные для нее верные. Или я что-то не понимаю?

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

Ещё раз: при программировании - "прошиваются" нолики. У Вас в первых четырех байтах одной прошивки 0C94624B, второй - 0C949551... После прошивки памяти этими двумя прошивками: первые четыре байта будет содержать 0С940041 (нолики из обоих файлов - сложатся, добавятся к содержимому ячеек памяти)...
А откуда BootLoader узнает стартовые адреса ваших программ. При "нормальной"(раздельной) загрузке Ваших файлов вектор 0 содержит команду перехода на "стартовый" адрес (у Вас там ещё какой-то вектор используется, и, может, - не один). Вектора всегда (за исключением BootLoader'а) используют фиксированные адреса для векторов прерываний. Они то и портятся при "заливке" двух прошивок одновременно...

То, что под вторую программу Вы отвели вторую половину памяти, не означает, что "стартовый" адрес второй программы = 8000. С этого адреса распологаются команды, но, команда, которая должна выполнится первой - совсем не с этого адреса!

Спасибо. С этим теперь стало понятно.



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

1. Одна из программ, по всей видимости, не должна использовать прерывания.
2. Труднее с вектором 0. Ваш транслятор (с языка Си - имхо) всегда в прошивку поместит команду по этому вектору (писать на ассемблере - не предлагаю, но там можно это обойти). Когда мне пришлось делать нечто подобное, я "заложил" в BootLoader функцию защиты вектора при заливке не первой программы: загрузчик не прописывал новую команду по этому вектору, но "выкусывал" из неё адрес, который сохранял в особой области памяти, и, в случае необходимости - передавал управление на этот адрес.

Такой вариант не подходит


Почему в одной программе вектор 0 присутствует,а в другой нет?

По этим адресам получается расположены вектора прерываний?
:04002800
:08006400
:08016000
:0801DC0

Разве переменная -Z(CODE)INTVEC не отвечает за место где будут размещаться вектора прерываний?

Вот еще два mapping

EGMENT SPACE START ADDRESS END ADDRESS SIZE TYPE ALIGN
======= ===== ============= =========== ==== ==== =====
INTVEC CODE 00008000 - 00008003 4 com 1
CODE CODE 00008004 - 0000AB17 2B14 rel 1
INITTAB CODE 0000AB18 - 0000AB25 E rel 0
NEAR_ID CODE 0000AB26 - 0000AB7E 59 rel 0
ABSOLUTE DATA 00000020 rel 0
DATA 00000034
DATA 000001C0
CSTACK DATA 00002000 - 00002054 55 dse 0
RSTACK DATA 00002055 - 0000206C 18 dse 0
NEAR_I DATA 0000206D - 000020C5 59 rel 0
NEAR_Z DATA 000020C6 - 0000277C 6B7 rel 0
CODE 00000028 - 0000002B 4 aseg
CODE 00000064 - 0000006B 8 aseg
CODE 00000160 - 00000167 8 aseg
CODE 000001DC - 000001E3 8 aseg

SEGMENT SPACE START ADDRESS END ADDRESS SIZE TYPE ALIGN
======= ===== ============= =========== ==== ==== =====
INTVEC CODE 00000000 - 00000003 4 com 1
CODE CODE 000001E4 - 00002CF7 2B14 rel 1
INITTAB CODE 00002CF8 - 00002D05 E rel 0
NEAR_ID CODE 00002D06 - 00002D5E 59 rel 0
ABSOLUTE DATA 00000020 rel 0
DATA 00000034
DATA 000001C0
CSTACK DATA 00002000 - 00002054 55 dse 0
RSTACK DATA 00002055 - 0000206C 18 dse 0
NEAR_I DATA 0000206D - 000020C5 59 rel 0
NEAR_Z DATA 000020C6 - 0000277C 6B7 rel 0
CODE 00000028 - 0000002B 4 aseg
CODE 00000064 - 0000006B 8 aseg
CODE 00000160 - 00000167 8 aseg
CODE 000001DC - 000001E3 8 aseg

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

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

Команда перехода на обработку этого прерывания содержится в обоих файлах

P.S. Действительно - соврал. Во второй программе эта команда лежит по адресу 8000.

У Вас: вторая программа - загрузчик?

P.P.S. Если вторая программа - не загрузчик, то зачем Вам весь этот "гемморой"? А, если - загрузчик, то зачем "зашивать" оба файла одновременно?

Файлы Flash.txt и FlashDef.txt содержат код одной и той же программы, отличаются же только местом расположения ее в памяти




Наверное это будет сложно реализовать, да и не очень удобно.

"Передвинуть" можно только для загрузчика, и то - не в произвольное место, а только в начало области загрузчика

Это наверное важно для начальной загрузки. А у меня в начале всегда будет грузится бутлоадер, а дальше передавать управление 1 или 2 программе. Неужели нельзя для второй программы создать эмуляцию,что она будет думать что работает так как будто записана в начало флеш памяти?

Не понимаю а как же я тогда смог передвинуть 0 вектор?

Э-э-э-э... Сложилось непонимание... Прочитайте внимательно раздел DS "Interrupts"...

Мой "вольный" перевод - разъяснение этого раздела:

Вы можите настройками Вашего транслятора разместить команды перехода на функции/процедуры обработки прерываний в любом месте памяти программ - никто не вправе Вам это запретить. Но! Микроконтроллер при возникновении условия прерывания перейдет на вектор прерывания, расположенный в таблице прерываний. Эта таблица прерываний для МК имеющих поддержку BootLoader'а может находится либо с начала Application Section, либо с начала Boot Loader Section (BLS). Всё! Третьего - не дано! Чтобы управление передалось на "вектора", расположенные в произвольном месте памяти программ, необходимо, чтобы некая программа выполнила в это место переход... В посте №14 я Вам предложил это реализовать из BootLoader'а. Вы - отказались... Теперь Вы опять завели речь о эмуляции прерываний... Дежавю... Пошли на второй круг?

Спасибо большое,что отвечаете. Становится понятнее...

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

Мое решение:
Сначала грузится bootloader и ждет скажут ему прошивать или нет. Если нет, то он переходит к программе которая расположена в начале флеш памяти. Если пришла команда что нужно перепрошить, то производится загрузка во флеш по адресу 0. При загрузке проверяется что прошивка рабочая, например CRC это еще не реализовано, если не рабочая, то грузимся с адреса 8000, если рабочая то с адреса 0.

Bootloader работает с avrdude по com порту.
Есть идея другой реализации при прошивке записывать программу в свободное место на флеш, там проверять,если все верно то прошивать ее в начало флешки. Но это не гарантирует 100% работу.

Наверное я изобретаю велосипед, раз столько проблем

Другими словами: Вы храните в памяти программ с адреса 8000 копию прошивки МК? Зачет тогда такие сложности? Вероятно, будет гораздо проще в загрузчик вставить проверку целостности "основной" копии и, если она повреждена (или плохо "прошилась") банально переписать (скопировать "один к одному") память программ из адресов 8000-ХХХХ в 0000-ХХХХ... А, если новая прошивка с адреса 0000 - верная (перепрошивка прошла успешно), то сделать резервную копию в адресах 8000-ХХХХ. Т.е. программа-приложение всегда работает (размещена) с адреса 0, а с адреса 8000 - резервная копия ("байт в байт") для возможного восстановления программы загрузчиком при её (программы-приложения) восстановлении.

Это я и рассматривал как второй вариант, просто я не нашел как при прошивке через avrdude указать с какого адреса начинать писать, я ему просто даю hex файл d котором прописаны все адреса. Буду разбираться как это сделать. Спасибо за помощь

Та-а-а-к... Опять я не понимаю: что Вы не понимаете?... Временно забудьте про avrdude... С помощью avrdude Вы прошьёте свой загрузчик, который:
1. По разработанному Вами протоколу примет новую программу-приложение в разработанном Вами формате (программу, которая взаимодействует с Вашим загрузчиком Вам предстоит разработать). Приём, скорее всего, будет вестись по интерфейсу, который Ваш прибор имеет "наружу" (RS232, RS485, USB, что-то там ещё...).
2. Принимать новую программу-приложение загрузчик будет кусочками (скорее всего равными размеру страницы), проверять контрольную сумму (при несовпадении контрольной суммы загрузчик должен "переспросить" Вашу программу - "попросить" повторить последний кусочек, но не более N раз) и записывать в Aplication Section, начиная с адреса 0 - первый кусочек, с адреса SIZEPAGE - второй кусочек, с адреса 2*SIZEPAGE - третий кусочек ...
3. После каждой прошивки кусочка программы-приложения загрузчик будет проверять правильность "прошивки" этого кусочка (считыванием из памяти программ и сравнением с содержимым приёмного буфера). При несовпадении - попытаться прошить кусочек ещё раз (N раз).
4. Когда программа-приложение будет записана загрузчиком в память программ, загрузчик сделает её резервную копию: скопирует "байт в байт" информацию из памяти программ 0000-ХХХХ в память программ 8000-ХХХХ (так же контролируя процесс).
5. Запустит программу-приложение.
6. Если какой-то из пунктов 1-3 завершится аварийно: программа загрузчик восстановит предыдущую программу-приложение, скопировав память программ из 8000-ХХХХ в 0000-ХХХХ (всё так же - с контролем процесса).

Всё вышеперечисленное - имхо. Вы можете "пойти другим путём"...

Насколько я понимаю - тут должны быть два разных подхода к прошивке памяти: Bootloader и резервная копия прошивки программируется с помощью программатора (того-же AVR Dude) а вот та программа, которую вы хотите удаленно прошивать принимается уже самим Bootloader например по UART и прошивается в программную память по методу Self programming под управлением Bootloader, а не программатора.

это признаки паранойи?
Бутлоадер ведь всегда остается в рабочем состоянии это гарантируется фузами запрета записи в BOOT секцию, даже если прошивка залилась неверно, ее можно удаленно перепрошить повторно. А вот секция кода никак не защищена, бутлоадер может с полным успехом убить обе копии программы, поэтому хранить вторую копию по адресу 0x8000 не имеет смысла. Уж если действительно нужна резервная копия - то ставьте внешнюю eeprom'ку с "железным" Write Protection'ом.


Палыч, тонкий намек на смену профессии