Jump to content

    

обновление прошивки через эзернет-чо требуется.

Запускать обмен по ARP, устанавливать TCP-сессию и прочее-прочее - всё равно нужно.

То что "унутри железный" - это наоборот минус. Когда обнаружится баг в нём железном, то исправить Вы его уже не сможете. Поэтому такое "железное" лучше не использовать.

Ни ARP поддерживать, ни устанавливать TCP сессию на нем не надо. Все это реализует железка.

Для TCP cервера надо поднять серверный  сокет( прописать его MAC, IP и порт для прослушивания.И активировать парочку клиентских сокетов. Дальше или ручной опрос сокетов на наличие данных или включить прерывания.

Share this post


Link to post
Share on other sites
4 минуты назад, jcxz сказал:

Зачем?

Это увеличивает сложность загрузчика, соответственно (неминуемо) - уменьшает вероятность его безглючной работы. А баг в загрузчике - он много хуже чем баг в основном ПО.

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

Share this post


Link to post
Share on other sites

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

в ОЗУ для считывания принятого пакета из сокета.

Share this post


Link to post
Share on other sites
3 минуты назад, Kabdim сказал:

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

Кирпич оживляется элементарно подключением и прошивкой по JTAG или UART, так как заводской ROM-загрузчик никто не отменял.

Я это говорю не на пустом месте: у нас был печальный опыт: сделали баг в загрузчике, который проявился только гораздо позже, когда устройство находилось уже в серийном производстве: вышла новая ревизия микросхем SPI-флешь (в которые сохранялась прошивка) и если со старой ревизией баг не проявлялся, то в новой он проявился. Когда устройств было выпущено уже довольно много и они уже стояли на объектах заказчика. И это при том, что этот загрузчик был минимальным! Только переписывал прошивку из SPI-флешь во флешь программ.

А если загрузчик многократно сложнее - с приёмом и обработкой протокола обмена? Насколько вырастает вероятность бага?

Share this post


Link to post
Share on other sites

2 Arlleex - а зачем из основного приложения деинить контроллер и перешивать.

Установить признак во флэше и уйти на перезагрузку - а при старте смотреть кого стартовать-бутлоалер или

рабочее приложение?

Share this post


Link to post
Share on other sites
3 минуты назад, KRTPC сказал:

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

в ОЗУ для считывания принятого пакета из сокета.

Когда наступите на грабли в этом железном эзернете, вот тогда в реале ощутите всю его "прелесть".   :-D

Share this post


Link to post
Share on other sites

Вы производителям железа совсем не доверяете? В частности errate?

З.Ы. Встроенная собака в нем работает нормально. Да я и в AVR не жаловался...

 

Share this post


Link to post
Share on other sites
8 минут назад, KRTPC сказал:

Вы производителям железа совсем не доверяете? В частности errate?

З.Ы. Встроенная собака в нем работает нормально. Да я и в AVR не жаловался...

Ну а Вы сами посмотрите на errata - если там в железе уже столько багов, то сколько ещё не выявленных? И сколько ещё во встроенном ПО их? Вы разве не видели ПО (на компе) которое обновляется годами - баги исправляются и исправляются? Думаете что в Wiznete сидят идеальные программёры никогда не делающие багов?  ;))))

Не доверяю, так как за свою практику уже многократно наступал на них. И коллеги наступали. И вообще стараюсь придерживаться правила: "Если в составе устройства есть что-то, имеющее встроенное ПО, то это ПО должно быть обновляемо через стандартный интерфейс обновления прошивки устройства". Именно так мы в последнее время и делаем, и уже не раз удалённо обновляли прошивки в GSM-модулях, в PLC-модулях (покупных), которые стоят в наших устройствах.

Share this post


Link to post
Share on other sites
Just now, KRTPC said:

а зачем из основного приложения деинить контроллер и перешивать.

Установить признак во флэше и уйти на перезагрузку - а при старте смотреть кого стартовать-бутлоалер или

рабочее приложение?

Из основного деинициализировать не нужно - зачем? А вот насчет перешивать... Ну вот как дать железке понять в процессе работы основного приложения, что ей пора бы паковать чемоданы обновиться? Естественно по этому же самому интерфейсу Ethernet послать команду - "Please, тут прошивочка есть новая, ее как бы надо бы прошить, типа...", для чего (с учетом вышеописанного механизма) по приему этой самой команды МК устанавливает флаг-признак "надо обновиться" и делает сброс. А при перезагрузке - штатная работа, описанная мною во втором посте (МК смотрит на флаг, видит, что надо обновиться, выходит в main() загрузчика и дальше работает протокол обновления прошивки). Естественно, что следует ответственно продумать логику перехода на основное приложение, ведь если основного приложения нет, кому передавать управление? Правильно, надо оставаться в загрузчике. Условий тут множество, на самом деле. У меня еще одним из условий является корректность доступа к EEPROM, в которой лежит флажок.

Но имея только лишь один интерфейс наружу, помимо всего прочего нужно продумать, как бы из основного приложения с запоротым механизмом перехода в загрузчик все-таки туда попасть. Можно после обновления, например, перейти в боевую прошивку, и ожидать там некоторое "время подтверждения связи", в течение которого пользователь со стороны ПК должен нажать кнопочку "ОК", по которой придет та же самая команда, как при "CONNECT". И только сейчас флажок-признак можно будет сбросить. Но тогда логику флажка в загрузчике поменять. В общем, вариантов много. Сейчас мне пока что некогда, но я доберусь еще до своего загрузчика и сделаю так, чтобы даже при запоротом приложении можно было перешиться, не вскрывая корпус девайса.

Share this post


Link to post
Share on other sites
2 minutes ago, Arlleex said:

У меня еще одним из условий является корректность доступа к EEPROM, в которой лежит флажок.

А смысл класть флажок в EEPROM, если RAM есть?

Share this post


Link to post
Share on other sites
Just now, aaarrr said:

А смысл класть флажок в EEPROM, если RAM есть?

Так а если в процессе перешивки (стирание, запись) питание отвалится, или еще какая непредвиденная штука - как узнаем, что прошилось все успешно?

Share this post


Link to post
Share on other sites
1 minute ago, Arlleex said:

Так а если в процессе перешивки (стирание, запись) питание отвалится, или еще какая непредвиденная штука - как узнаем, что прошилось все успешно?

Так CRC основной части ПО надо проверять перед передачей управления из загрузчика.

Share this post


Link to post
Share on other sites
13 минут назад, Arlleex сказал:

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

Достаточно держать бэкап предыдущей прошивки. И по некоторому условию делать откат.

Share this post


Link to post
Share on other sites
Just now, aaarrr said:

Так CRC основной части ПО надо проверять перед передачей управления из загрузчика.

Так и есть. Проверяется CRC32 и только если она совпадает - стираю флаг и сбрасываюсь (после сброса загрузчик уже передаст управление в основную программу). Это признак, что все прошилось корректно.

Если же разместить флаг в ОЗУ, то, например, происходит следующая последовательность действий:

1. Работает основное ПО. Пришла команда на обновление ПО. Установили флаг-признак "необходимо обновиться" и сделали сброс (или переход в загрузчик другим образом).

2. Загрузчик видит в ОЗУ установленный флаг, что нужно перейти в загрузчик - и переходит в него.

3. Работает протокол обмена, стерли Flash, начали записывать... Пропало питание.

4. Появилось питание, МК загружается, проверяет флажок - а там он сброшен, он же в ОЗУ был. Значит обновляться не надо. Значит штатная работа - переходим на основное приложение. Если, к тому же, сделать элементарную проверку, что там не мусор лежит (проверяем значение MSP и вектора сброса основного приложения на хоть какую-то корректность), то покажется, что все хорошо и передавать управление можно основному ПО. Но дописать то мы не успели (см. п. 3). Получили кирпич.

Но можно, конечно, в образе прошивки хранить CRC32 этой прошивки и при старте загрузчика сравнивать всю прошивку с CRC32 во Flash. И тогда можно делать флажок в ОЗУ. Но, как мне кажется, проверять CRC32 всей прошивки всегда в загрузчике - расточительство... Хотя имеет место быть. ИМХО.

 

Just now, jcxz said:

Достаточно держать бэкап предыдущей прошивки. И по некоторому условию делать откат.

Так и будет, скорее всего. SD карточка на борту есть, поэтому виден свет в конце тоннеля =)

Edited by Arlleex

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this