Перейти к содержанию
    

Что значит "уходит в цикл и кирпич"? ПО РЕСЕТУ МЫ ВСЕГДА ПОПАДАЕМ в БУТЛОАДЕР!
И что? А без дополнительных телодвижений мы из бутлодера уходим в прошивку. А про телодвижения было расписано по четыре раза на предыдущих страницах - какие и зачем. Вот возьмите и прочитайте. И не пытайтесь впарить мне как открытие решение, которое я давно использую и которое описал на предыдущих страницах (уже, похоже, не один раз описал).

ЗАЧЕМ ПРОВЕРЯТЬ КОНТРОЛЬНУЮ СУММУ ЕСЛИ ВСЕГДА МОЖНО ПЕРЕЗАЛИТЬ?
Вы перезаливаете после каждого включения? Или у вас загрузчик все же при нормальном включении как-то определяет - запускать приложение или его там нет?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А вот тут вдруг у меня возникло такое подозрение...

 

Может человек говорит про микробут или что-то типа.

То есть загрузчик который берет прошивку рабочую с СД карты или что-то типа того? То есть у него нет жестко прописываемой основной программы...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

То есть у него нет жестко прописываемой основной программы...

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Смысла в проверке контрольной суммы по прежнему нет.

Всегда по ресету с кнопкой попадем в бутлодырь и будем сидеть до новой прошивки.

Никаких кирпичей..

 

Я проверяю только примитив - если в начале лежит стекпойнтер 0x2000XXX.

 

Правда, сейчас добавил EEPROM - бутлодырь если была заливка, прыгает на программу,

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

Программа тоже проверяет на старте эту ячейку и пишет туда 0xFE, если там его нет.

 

Особого смысла в этом нет, это больше для "технически одаренных" пользователей.

Так легче объяснить, что "не играет", значит неправильную программу залил.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Извращенная логика%:)...

 

Забавно что вы не проверяете целостность прошивки. А если залилось что-то не так? А если флэш поврежден?

Счастливые люди приборы которых не могут ничего испортить:)))...

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Извращенная логика%:)...

 

Забавно что вы не проверяете целостность прошивки. А если залилось что-то не так? А если флэш поврежден?

Счастливые люди приборы которых не могут ничего испортить:)))...

 

Бутлоадер может выдать контрольную сумму для диапазона аддрессов.

Если флэш поврежден, то ничего не поможет.

Контрольная сумма не спасает от повреждения.

Там на 99.9% повреждения будут от неправильно написаной программы, чем по другим причинам.

 

Но в принципе пойнт понятен. Спасибо

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Контрольная сумма не спасает от повреждения.

Смотря повреждения чего:)..

У меня одно устройство могло поднять тревогу и вызвать бригаду со стоимостью выезда 10-20 тысяч баксов. Если это бы произошло из-за того что прошивка неправильно записана во флэш мне бы сделали повреждение головы:).

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

Третье устройство могло поехать и ударить в дорогущий микроскоп дорогущим объектом.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну что ж, идем на очередной круг. Не всегда есть возможность подойти и передернуть питание. Бывает, что обновление хочется сделать удаленно. И если во время такого обновления происходит сбой (связи), то с вашей проверкой на непустой сектор вы запустите нерабочее приложение и придется таки посылать человека жать на кнопку и передергивать питание. В моей и в Golikov A. реализации загрузчик обнаружит испорченное приложение и останется в режиме ожидания загрузки, давая возможность повторить загрузку. И ради чего ваши жертвы? Ради экономии 20 байт и 10 мс на проверку CRC приложения?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я в "крупных" МК использую две области: application и image.

Когда необходимо обновить прошивку, код, работающий в application (по сути сама программа) стирает image, получает и записывает image, проверяет CRC, версию железа и версию прошивки и после этого передает управление загрузчику (через SoftReset). До тех пор, или в случае некорректного/старого image программа работает и практически не чувствует, что идет какое-то обновление.

Загрузчик проверяет корректность и версию как application, так и image. Если все CRC корректны и версия application >= версии image, то управление передается application. Если CRC у application не корректна, а у image корректна, то image расшифровывается и переписывается в application, как и в том случе, если версия image новее, затем перезагрузка. Если все CRC не корректны, то остаемся в загрузчике и мигаем светодиодом "SOS". Некоторые функции как подсчет CRC (в том числе на лету, по ходу выполнения программы), расшифровка и т.п. вынесены в область загрузчика и application их экспортирует по фиксированным адресам из таблицы экспорта (последние 240 байт загрузчика).

Из бонусов image шифрованный, сложно получить кирпич, обновление мгновенное (минимально возможное время, т.к. основная часть тратится на передачу image по GPRS|SD-карты|RS485 и т.п., а application при этом работает). Из минусов: расход памяти практически удвоенный (но image можно держать во внешней медленной/последовательной памяти, т.к. он шифрован и не отличается от того, что передается Заказчику свободно в качестве обновления), загрузчик поддерживает лишь базовые варианты управления без возможности модернизации.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У меня обновление на лету. Тоже шифрование. Нет необходимости в дополнительной памяти. В случае сбоя обновления меня не напрягает повторить. Обновление через UART. Будет GPRS - буду думать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И ради чего ваши жертвы? Ради экономии 20 байт и 10 мс на проверку CRC приложения?

Я просто описал, как оно у меня щас сделано и не призываю делать так всех.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну что ж, идем на очередной круг. Не всегда есть возможность подойти и передернуть питание. Бывает, что обновление хочется сделать удаленно. И если во время такого обновления происходит сбой (связи), то с вашей проверкой на непустой сектор вы запустите нерабочее приложение и придется таки посылать человека жать на кнопку и передергивать питание. В моей и в Golikov A. реализации загрузчик обнаружит испорченное приложение и останется в режиме ожидания загрузки, давая возможность повторить загрузку. И ради чего ваши жертвы? Ради экономии 20 байт и 10 мс на проверку CRC приложения?

 

Тем не менее: "придется таки посылать человека жать на кнопку" и "получаем кирпич" немного разные вещи

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ага%) Есть и на этот случай история у меня из раздела гусарских баллад. Был на фирме программист любил сделать код и не изнурял себя защитами. В случае не запуска на объекте он всегда был готово на обновления и не видел почему те кто на объекте так ругаются.

 

Вот в итоге люди на объекте устали и вызывали его на обновление в командировку. Он приехал с ноутбуком, программатором и говорит, ну где прибор, ща все исправим. Ему дали лопату, указали место и сказали: прибор на глубине 4 метров мерзлой глины под землей, выкопай его, достань и обнови, а потом там в яме его подключи так как туда выведена вся подводка и гермокапсула рабочая.

 

Уволился он....

 

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

 

Так что кнопка нужна, но на крайний случай...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Что-то пример от ST мня загоняет в ступор

 

это процедура стирания флеша из исходника к AN3374

STM32F2xx in-application programming using the USART

 

/**
  * @brief  This function does an erase of all user flash area
  * @param  StartSector: start of user flash area
  * @retval 0: user flash area successfully erased
  *         1: error occurred
  */
uint32_t FLASH_If_Erase(uint32_t StartSector)
{
  uint32_t UserStartSector = FLASH_Sector_1, i = 0;

  /* Get the sector where start the user flash area */
  UserStartSector = GetSector(APPLICATION_ADDRESS);

  for(i = UserStartSector; i <= FLASH_Sector_11; i += 8)
  {
    /* Device voltage range supposed to be [2.7V to 3.6V], the operation will
       be done by word */ 
    if (FLASH_EraseSector(i, VoltageRange_3) != FLASH_COMPLETE)
    {
      /* Error occurred while page erase */
      return (1);
    }
  }
  
  return (0);
}

 

 

Зачем там i+=8 ? Ну i+=4 я бы еще как то понял, т.к. запись далее идет по 32 бита.

Но сектор же стирается целиком ? Зачем вызывать процедуру стирания sectorlen/8 раз ?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...