[ELEKTROS 0]

Читаю читаю и вижу говорим об одном и том же, я больше про второй вариант, вы про два.

Так что в итоге? Кто нибудь начал пробывать делать?

[doom13 0]

Так что в итоге? Кто нибудь начал пробывать делать?

 

Я говорил о том, что уже давно стабильно работает:), правда, на f2812

 

Читаю читаю и вижу говорим об одном и том же, я больше про второй вариант, вы про два.

 

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

[ELEKTROS 0]

Поделитесь или проект как всегда коммерческий?

[prst 0]

Как минимум, необходимо конфигурационными ногами выбрать вариант загрузки процессора, без этого процессор вообще не стартанёт.

1. Для варианта OTP custom bootloader необходимо выбрать режим Boot to OTP 0x3D7800 (gpio18 - 0, gpio29 - 0, gpio34 - 1). При включении питания управление передаётся OTP custom bootloader, который умеет принимать прошивку по can и заливать её во флэш, умеет стартовать уже имеющуюся во флэши прошивку. А уже основная программа понимает команду перехода на OTP custom bootloader.

2. Для варианта custom bootloader in flash необходимо выбрать режим Boot to flash 0x3F7FF6 (gpio18 - 1, gpio29 - 1, gpio34 - 1). Для этого варианта бьём флэш на две части, при включении питания стартует custom bootloader in flash, который умеет заливать прошивку по can (в моём случае can + ethernet) и стартовать залитую прошивку. Основная программа понимает команду перехода в режим загрузчика.

1) - не получится судя по всему, и вот по чему, я попробовал на днях склеить версию от TI с библиотекой для Flash (2.10), так вот размер получился около 1,5кб, а у OTP лимит в 1кб. Хакать библиотеку и срезать жирок не видится пока перспективным, как минимум на работе скажут - (не проверена = не гарантирует, или есть риск)

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

 

Щас думаю как можно принять кусочек, каким-то образом сменить бут-пины, бутнуться с поддержкой флэша, записать, потом снова бутнуться в ОТП, принять следущий N+1 кусок и нова перебутнуться.... и так пока все куски не прийму.

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

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

 

Читаю читаю и вижу говорим об одном и том же, я больше про второй вариант, вы про два.

Так что в итоге? Кто нибудь начал пробывать делать?

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

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

[doom13 0]

1) - не получится судя по всему, и вот по чему, я попробовал на днях склеить версию от TI с библиотекой для Flash (2.10), так вот размер получился около 1,5кб, а у OTP лимит в 1кб.

Хакать библиотеку и срезать жирок не видится пока перспективным, как минимум на работе скажут - (не проверена = не гарантирует, или есть риск)

 

Были предположения, что не поместится при использовании Flash_API. Для tms320c6455 чтобы загрузить пршивку с внешней флэш-памяти необходимо при помощи встроенного в ОТР загрузчика (может грузить прошивку размером до 1кБ) загрузить загрузчик "второго уровня" (размер не более 1 кБ), который уже умеет заливать любой размер кода с флэша в рам. Загрузчик "второго уровня" написан на ASMe. Думаю, здесь необходимо идти тем же путём, чтоб всё влезло - использовать ASM.

 

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

Вариант с разбиением флэша и использованием Flash_API - реализуем. Кто сказал что необходимо принимать всю прошивку и сохронять в ОЗУ? Принимаем пакет (can-посылку, tftp-пакет) и запизываем во флэш. Выше алгоритм работы уже описан посмотрите ещё раз. Реализуем can-протокол с командами перехода в режим загрузчика, стирания флэша, записи данных (после приёма записываем данные (например, 8 байт) и посылаем ответ, не накапливаем всю прошивку), команда перехода в режим выполнения программы по окончании приёма. В качестве команд можно использовать разный can ID, можно один can ID, но с посылкой команд.

 

Щас думаю как можно принять кусочек, каким-то образом сменить бут-пины, бутнуться с поддержкой флэша, записать, потом снова бутнуться в ОТП, принять следущий N+1 кусок и нова перебутнуться.... и так пока все куски не прийму.

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

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

 

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

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

Изменено 21 апреля, 2014 пользователем doom13

[doom13 0]

Поделитесь или проект как всегда коммерческий?

 

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

Принцип работы был описан выше.

 

 

Правда, проект для DSP TMS320F2812, но принцип остаётся тем же.

boot.rar

[prst 0]

Были предположения, что не поместится при использовании Flash_API. Для tms320c6455 чтобы загрузить пршивку с внешней флэш-памяти необходимо при помощи встроенного в ОТР загрузчика (может грузить прошивку размером до 1кБ) загрузить загрузчик "второго уровня" (размер не более 1 кБ), который уже умеет заливать любой размер кода с флэша в рам. Загрузчик "второго уровня" написан на ASMe. Думаю, здесь необходимо идти тем же путём, чтоб всё влезло - использовать ASM.

Во втором мануале, который Вы называли, есть упоминание о примере необходимого Вам загрузчика (f280x_otp2can_boot_rom), попробуйте поискать, думаю, он написан на ASMe.

Сегодня я смержил вот ту самую что дает TI - f280x_otp2can_boot_rom (переделанную под мой 28335) + Flash_API и в 2 кБ, чтоб оно влезло в M0,M1 SARAM. Но толку всё равно мало, потому что OTP имеет размер 1к... бесперспективный путь.

Не знаю, даст ли мне еще это какую-то пользу. Единственный способ без него это както разместить часть кода в флэщ, а для этого нужно... опять-25... ;)

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

видимо прийдется както из серии:

- принять 2й загрузчик и поместить в память (он уже должен уметь флеш писать)

- пригнуть на него

- начать запрос данных прошивки

- записывать частями (сегодня интересный эксперемент провел)

 

Об эксперементе:

Спеерва в чем проблема - в том что на самом деле не все 32кБ ОЗУ доступны, у L0 кусочек откушен под какотой треш(забыл точно под что), короче ложка дегтя в бочке мёда. А секции в флэш 32кБ. Итак получается что мы не можем по кану принять полную секцию чтоб её всю зажеч. По этому я проверил писать кусками.

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

А это как минимум дает зеленый свет в сторону загрузчика 2го уровня который принимает по КАНу в апмять и оттуда зажигает флэш.

 

Вариант с разбиением флэша и использованием Flash_API - реализуем. Кто сказал что необходимо принимать всю прошивку и сохронять в ОЗУ? Принимаем пакет (can-посылку, tftp-пакет) и запизываем во флэш. Выше алгоритм работы уже описан посмотрите ещё раз. Реализуем can-протокол с командами перехода в режим загрузчика, стирания флэша, записи данных (после приёма записываем данные (например, 8 байт) и посылаем ответ, не накапливаем всю прошивку), команда перехода в режим выполнения программы по окончании приёма. В качестве команд можно использовать разный can ID, можно один can ID, но с посылкой команд.

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

 

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

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

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

Одно точно - чтоб сменить режим загрузки пины буда должны быть изменены.

 

То есть, на текущий момент у меня только частицы этой мазайки.

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

 

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

Принцип работы был описан выше.

 

Правда, проект для DSP TMS320F2812, но принцип остаётся тем же.

О, мне тоже интересно будет поразбираться с вашим результирующем кодом. Завтра покапаюсь в нем.

В случае чего то под 28335 переделать и подправить под себя, не так уж сложно ))

[doom13 0]

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

 

А можно и по 8 байт, для CANa наверное даже удобнее (принял -> записал -> подтвердил приём (запись)).

 

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

видимо прийдется както из серии:

- принять 2й загрузчик и поместить в память (он уже должен уметь флеш писать)

- пригнуть на него

- начать запрос данных прошивки

 

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

 

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

Одно точно - чтоб сменить режим загрузки пины буда должны быть изменены.

 

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

В моём случае Boot to flash 0x3F7FF6.

 

Тоже глянул пример загрузчика от Техаса для ОТР. Их загрузчик умеет принимать прошивку по CAN и склаывать в RAM. После окончания приёма прошивки происходит переход на адрес расположения загруженной пршивки(в RAM).

Т.е. дальше можно работать при условии, что загруженная по CANу в RAM прошивка и есть загрузчик "второго уровня", который умеет записывать флэш и осуществлять переход на адрес флэша, где находится рабочая прошивка.

Т.е. загрузчик "второго уровня" после загрузки в RAM ожидает приёма новой прошивки или сразу переходит на адрес флэша, где лежит ранее загруженная прошивка.

Что касается конфигурационных пинов, то здесь выбирается режим Boot to OTP 0x3D7800 (железно), нет никакой смены режима загрузки.

1. Загрузчик "первого уровня" стартует при включеннии питания.

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

3. Загрузчик "первого уровня" принимает прошивку "загрузчика второго уровня" и записывает в RAM.

4. После записи в RAM загрузчика "второго уровня" загрузчик "первого уровня" стартует его.

5. Загрузчик "второго уровня" либо перезаписывает флэш, либо стартует уже существующую прошивку.

 

Размер кода их примера 608 байт, т.е. вполне влазит в ОТР.

[prst 0]

А можно и по 8 байт, для CANa наверное даже удобнее (принял -> записал -> подтвердил приём (запись)).

doom13, Ваш код пригодился, спасибо!

Высмотрел там самую главную константу, которая разрешила одну мою проблему, долго не мог понять почему у меня работатет на передачу а на прием не работает... Думал что посылая в ext. режиме ID=1 это равносильно что и в стандартном (не знал просто что они не совместимы). тоесть в ext это на на самом деле 0x80000001 вместо 0x01.

Так что ваш код помог. :)

Но вот у меня какой вопрос появился, я уже сделал драфт версию загрузчика 1го уровня и 2го, но еще не прошивал в OTP, на днях планирую...

Меня вот что сильно беспокоит, я не нашел явного ответа в документации от TI, у них сказано что должен быть CAN ID=0x01 но не сказано, а обязательно ли?

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

Это щас главная делема. Так как например главная проблема что у меня не работает CAN-USB который может корректно работать с CAN полноценно. А тот что есть он умеет только в ext режиме, а это ведь адресс 0x80000001 вместо 0x01.

 

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

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

В моём случае Boot to flash 0x3F7FF6.

Тоже глянул пример загрузчика от Техаса для ОТР. Их загрузчик умеет принимать прошивку по CAN и склаывать в RAM. После окончания приёма прошивки происходит переход на адрес расположения загруженной пршивки(в RAM).

Т.е. дальше можно работать при условии, что загруженная по CANу в RAM прошивка и есть загрузчик "второго уровня", который умеет записывать флэш и осуществлять переход на адрес флэша, где находится рабочая прошивка.

Т.е. загрузчик "второго уровня" после загрузки в RAM ожидает приёма новой прошивки или сразу переходит на адрес флэша, где лежит ранее загруженная прошивка.

Что касается конфигурационных пинов, то здесь выбирается режим Boot to OTP 0x3D7800 (железно), нет никакой смены режима загрузки.

1. Загрузчик "первого уровня" стартует при включеннии питания.

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

3. Загрузчик "первого уровня" принимает прошивку "загрузчика второго уровня" и записывает в RAM.

4. После записи в RAM загрузчика "второго уровня" загрузчик "первого уровня" стартует его.

5. Загрузчик "второго уровня" либо перезаписывает флэш, либо стартует уже существующую прошивку.

Размер кода их примера 608 байт, т.е. вполне влазит в ОТР.

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

[doom13 0]

Меня вот что сильно беспокоит, я не нашел явного ответа в документации от TI, у них сказано что должен быть CAN ID=0x01 но не сказано, а обязательно ли?

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

 

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

 

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

 

Т.е. пока не будет принят код 2-го загрузчика процессор будет висеть в ожидании? Или Вам такой вариант подходит?

 

[prst 0]

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

 

Т.е. пока не будет принят код 2-го загрузчика процессор будет висеть в ожидании? Или Вам такой вариант подходит?

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

да, подходит. в 1м просто реализую ожидание, и если не будет скажем 5сек стрима, то джамп по адресам флэша, классический подход. ))) А уж коль первый принят по CAN вероятно второй обязан также прилететь и быть принятым. собственно такой логикой руководствуюсь.

 

 

[doom13 0]

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

да, подходит. в 1м просто реализую ожидание, и если не будет скажем 5сек стрима, то джамп по адресам флэша, классический подход. ))) А уж коль первый принят по CAN вероятно второй обязан также прилететь и быть принятым. собственно такой логикой руководствуюсь.

 

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

 

[prst 0]

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

предложение про флаг не понял

(точнее то что понял не подходит, у меня же в флеш ни чего не пишется в промежутке)

что вы имеете ввиду?

[doom13 0]

предложение про флаг не понял

(точнее то что понял не подходит, у меня же в флеш ни чего не пишется в промежутке)

что вы имеете ввиду?

 

Загрузчик запускается, при наличии прошивки во флэш-памяти и отсутствии необходимости принимать новую "прыгает" на адрес программы во флэш-памяти. При необходимости загрузки новой прошивки программа принимает команду перехода, выставляет флаг перехода в режим загрузчика (у меня было два байта в RAM отведено под этот флаг) и "прыгает" на адрес загрузчика. Теперь загрузчик запускается, проверяет флаг по определённому в RAM адресу и понимает, что был переход по команде и ему необходимо ожидать приёма прошивки и/или загрузчика второго уровня. Принимает, затирает флаг, переходит на выполнение программы. Можно наверное и без флага, счётчик запускать, но мне так удобно было.

[prst 0]

Дошел до этапа, когда судя по всему, данные с первого уровня правильно копируются в RAM и от туда, уже "планируемым" загрузчиком второго уровня, потом копируются в DSP FLASH.

Но я вот чего еще не могу понять, запутался окончательно...

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

Вот мой кусочек кода

if( SectStartAdr<0x338000/*0x338000-0x33FF7F*/) g_Write_Stage=WR_SECTOR_B;
         else
         if( SectStartAdr<0x330000/*0x330000-0x337FFF*/) g_Write_Stage=WR_SECTOR_C;
         else
         if( SectStartAdr<0x32FFFF/*0x328000-0x32FFFF*/) g_Write_Stage=WR_SECTOR_D;
         else
         if( SectStartAdr<0x31FFFF/*0x320000-0x327FFF*/) g_Write_Stage=WR_SECTOR_E;
         else
         if( SectStartAdr<0x317FFF/*0x318000-0x31FFFF*/) g_Write_Stage=WR_SECTOR_F;
         else
         if( SectStartAdr<0x30FFFF/*0x310000-0x317FFF*/) g_Write_Stage=WR_SECTOR_G;
         else
         if( SectStartAdr<0x307FFF/*0x308000-0x30FFFF*/) g_Write_Stage=WR_FINISH;
         if ( WR_FINISH != g_Write_Stage ) {
             if ( u16_ErrCode==STATUS_SUCCESS ) {
                 // `Size` bytes write to Flash
                 if ( Size < 4*1024 )
                 {
                     u32_FlashWrSize = Size;//u32_FS;
                     u16_ErrCode =
                         Flash_Program ( (Uint16*)SectStartAdr, (Uint16*)DataIn, u32_FlashWrSize, &FlashStatus );
                 }
                 if ( u16_ErrCode==STATUS_SUCCESS ) {
                     g_Write_Stage = WR_FINISH;
                 } else {
                     return u16_ErrCode; //STATUS_FAIL_PROGRAM;
                 }
             }
         }

 

Так вот, как я понял: Флэш секция-А начинается с 0x338000, а почему то я встречаю часто что бут делают с 0x3F7FF6

 

Вот, даже в исходниках от TI

//---------------------------------------------------------------------------
      // Fixed boot entry points:
      #define FLASH_ENTRY_POINT 0x3F7FF6
      #define OTP_ENTRY_POINT   0x3D7800
      //#define RAM_ENTRY_POINT   0x000000
      #define RAM_ENTRY_POINT   0x00F000
      #define PASSWORD_LOCATION 0x3F7FF8

Возможно это и правильно, но чтото я заблудился...

 

кстати у вас doom13 тоже самое в коде

__inline void GotoStartFLASH() { asm(" LB 0x3F7FF6"); }

 

http://www.ti.com/lit/an/spra958l/spra958l.pdf тоже об этом говорят на стр:32 только сказано что для моего проца это должен быть адрес 0x3F7FFE так как у меня TMS320F28335.

0x3F7FFE это Jump-to-Flash, НО! У меня то OTP бут-пины буду всегда...(как и когда с него прыгать в влэш, это уже другой вопрос)

И ведь, 0x3F7FFE это судя по карте, это зарезервированное и неиспользуемое адресное пространство.

 

 

Так почему бы не прыгать сразу в начало флэша 0x338000 ?

 

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

 

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

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

 

 

Ну и второй вопрос:

На сколько я понимаю, для того чтоб мне слали то что я должен буду своим бутлоадером обновить, то это должен быть бинарик в формате *.bin. Который я должн буду предоставить, чтоб мне его отправили по CAN.

Как в хекс знаю, но это ж не то...

Так вот, а как правильно его с *.out сконвертировать в *.bin?