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

Проще всё-таки bin грузить.

1) Сервер есть всегда, т.к. он выполняет не только функцию обновления прошивок. Как у вас происходит удаленная перепрошивка? Сервера нет?
2) Да, есть такой минус. Поэтому в следующей версии запланирована возможность загрузки прошивки основной программой.
А теперь представьте, что вы выкачали новую прошивку, перепрошились и в ней оказался баг, из-за которого невозможно обновлять прошивки. Что делать в такой ситуации, если, на сколько я понял, ваш boot loader не умеет обновляться по интернету/ethernet'у.


Для создания бинарников использую стандартную кейловскую утилиту - fromelf.

О, слона-то я и не приметил! То что надо, спасибо!

И вызывается в User Run: fromelf.exe --bin --output "@L.bin" "#L"

Я же писал, поддержен WEB и по HTTP, абдейт в ручном и автоматическом режиме. В проекте не было необходимости программе следить за абдейтами на сервере в непрерывном режиме. Всё же инет не столь надежная штуковина.


Если сами пишите софт на C/C++ для ARM, то какую то нереальную представлялку пишите. Допустить такой баг можно в начале пути или по неопытности. Но есть тестовые устройства на которых делается прогон, контроль новой прошивки. Только затем абдейт. Обычно в новой добавляется какой либо функционал не влияющий на режим перехода в загрузчик.
Мои загрузчики умеют по UDP, TCP/IP, HTTP еще может и по USB, RS, CAN, I2C. Много было разных проектов с собственными загрузчиками на STM32Fxx у всех свои особенности.

А тут и освещать-то нечего.
Прислали платку с производства уже зашитую и залоченную.
Я с ней пык-мык - не шьётся... Но стирается и чип прекрасно виден jlink'ом.
При этом в среде keil нет никаких возможностей для снятия лока.
Почитал доку на jlink - и всё решилось за 1 сек при помощи утилиты j-flash.

Чип прекрасно виден jlink'ом и стирается. Это так, поскольку только доступ отладочных средств и программаторов закрыт. Во всех средах нет, по крайней мере я не нашёл из того что описано и доступно. Поскольку проц виден jlink_ом, и есть его исходники, можно предположить как открыть
проц не стирая программу. Снятие защиты и стирание флеша делается ~ следующим образом: 1) стирается сам флеш 2) затем тот самый байт защиты. Если пропустить, не дать выполниться 1), то второе снимит защиту и проц прочитается. Не проверял, работаетли это или есть защита и от этого.

Это не работает, читайте доку... При снятии защиты от чтения флеш будет автоматически стерт.

Дока -докой. А сам механиз защиты там софтовый и во флеше живёт. demiurg_spb же пишет ... и всё решилось.

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

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

Дык а можно поподробней? demiurg_spb не писал о том, что смог вычитать прогу из залоченного чипа. Он писал, что смог разлочить проц. При этом согласно доке флеш потерся.

Что такое "софтовый механизм защиты, живущий во флеше"?

Именно. Я стёр чип ещё до разлочки.

Так у вас у каждой железки белый IP? WEB и HTTP помогут только в локальной сети, если нет белого IP.


Такое ощущение, что вы робот и человеческие ошибки вам чужды. Допустить баг можно всегда и даже будучи опытным программистом. В некоторых ситуациях даже тестовые устройства могут не спасти, потому что они именно тестовые, а не находятся на реальном объекте. Вы читали про то, как NASA управляет марсоходом Coriosity? Несколько человек проверяют программный код очередного задания для марсохода, затем проверяют выполнение задания на Земле в услових приближенных к марсианским и все равно допускают ошибки! Везде есть человеческий фактор!

Так и что это даёт?
Своим загрузчиком под протектом я тоже это делаю, как мне нужно, при абдейте.


И так и так можно, в зависимости от битика установки. DHCP не проблема, был поддержан сразу.
Порт тоже указывается и прокидывается. По необходимости MAC маскарадиться.

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

Если контроллеры можно по пальцам рук пересчитать, то вполне можно и порты прокинуть, но когда их гораздо больше и разбросаны по всей стране и даже за рубежом, то вариант с сервером намного эффективнее. ИМХО.

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

Я где-то писал, что все время занимаюсь обновлением прошивок?

Поясните тогда для ясности.
... И если вы в режиме загрузчика, контролируете все время на сервере абдейты. Да, и если устойство во внутренней сети подключено к инету, как вы делаете прокидку без поддержки DHCP, указания порта в загрузчике.

Апдейты контролируются основной программой и, если появилась новая версия, контроллер перезагружается в bootloader и тянет прошивку. Поддержка DHCP есть и в bootloader'e, и в основной прошивке, так же в сети, к которой подключены контроллеры, присутствует DHCP. Порт сервера указывается в загрузчике и в основной программе. Проброс портов в таком случае не нужен.

Значит основная прога куда то лезет по сети? И если прошла ошибка через контрольную сумму, то после перезагрузки висяк обеспечен? Поскольку пишется сразу в память без доп анализа достоверности. А кто тогда в большой кучи фаерволов, роутеров, и тп обеспечивает не закрытость портов. Кто-то ручками должен прописать, так получается. И если сервер смениться и порты, то во всей кучи устройств надо менять. Неушто в uip, в 17K поддержан DHCP, потры?

Да, на этот же сервер по своим делам и попутно проверяет версию прошивки.

Что значит прошла ошибка через контрольную сумму? Прошивка скачивается блоками, у каждого блока проверяется CRC, а затем после записи всей прошивки, проверяется еще и общий CRC. Конечно теоретически можно принять мусор у которого CRC совпадает с правильным, но вероятность такого события ничтожно мала!
Как тогда вы обходите данную проблему?

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

И что в этом сложного? Делаем прошивку с новыми портами, обновляем на всех устройствах и переводим сервер на новые порты.

Я же выше писал. В 17к реализована поддержка DHCP, DNS, обработка UDP пакетов, перепрошивка по TCP в локальной сети, CRC.

облом. в stm32f407 нет криптопроца
придется что то свое колхозить

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

может есть где нибудь пример софтовой реализации AES декрипта под stm32 ?
буду признателен

елси не найдете конкретно для стм32, то на сайте атмела есть для атмела, но он писан на си

Как это нет?!?!
Глава 19 референс мануала!!!

Кроме РМ есть еще датащит, в котором сказано, что крипто есть в 417, а в 407 нет

Попробуйте Blowfish. У меня из проекта в проект кочует. Исходники есть.

Хм...действительно. Странно почему в референсе не написали...