[DogPawlowa 0]

... А на какие запросы у тебя отвечает загрузчик?" ...

При наличии в сети разных устройств кроме текущей версии нужно знать еще и тип устройства, чтобы прошивку от БМВ не прошить в Боинг :)

То есть желательно иметь команду запроса типа устройства по данному адресу.

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

[Сергей Борщ 126]

При наличии в сети разных устройств кроме текущей версии нужно знать еще и тип устройства, чтобы прошивку от БМВ не прошить в Боинг :)

А, ну да. У меня тип отвечается вместе с версией, поэтому я о нем и не подумал. Хорошо, все необходимые данные загрузчик может отдавать в одном ответе. Обзовем это "запросом конфигурации". Какие еще команды должен поддерживать загрузчик?

 

И понятное дело - для разных типов и даже для одного типа, но несовместимых версий железа разные ключи шифрования, так что БМВ не взлетит

[SapegoAL 0]

 
2 106 bytes of CODE memory
1 430 bytes of DATA memory (+ 8 absolute )

 

:)

 

Непонятно ещё какая то хрень записывает 4 байта по 00 адресу.

 

 

Короче оставлю пока 4к на бутлоадер и приступаю к отладке. Когда отлажу, тогда уберу оставшийся жирок.

[Waso 1]

Извиняюсь что лезу в чужую тему, но есть дилетантский вопрос по ней.

Мне нужно обеспечить перепрошиваемость устройства (sam7x256) через ethernet. http и ftp сервера уже реализованы. Я планирую через ftp заливать (декриптовать находу) бинарник в свободную часть флеши и, после успешной проверки CRC, переписывать reset-вектор чтобы он указывал на начало этого бинарника.

 

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

 

Прав ли я и смогу ли я избежать танцев с бубном вокруг бутлодера?

[Сергей Борщ 126]

Я планирую через ftp заливать (декриптовать находу) бинарник в свободную часть флеши и, после успешной проверки CRC, переписывать reset-вектор чтобы он указывал на начало этого бинарника.

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

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

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

[Waso 1]

Спасибо за совет!

Нашел апноты. Изучаю.

 

Safe and Secure Firmware Upgrade for AT91SAM Microcontrollers

Safe and Secure Bootloader Implementation

Safe and Secure Bootloader Implementation (source.zip)

 

[SapegoAL 0]

Ещё один вопрос, напрямую с бутлоадером не связанный а вот с IAR да.

 

Я решил разместить серийный номер изделия непосредственно в буте по фиксированному адресу.

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

 

Так вот такой вопрос.

В приложении я объявляю переменную таким образом

 

extern const uint32_t __flash SerialNN @ BOOTSERIAL; // Серийный номер

 

Так IAR генерит в hex файле по указаному адресу 00000000. Что в свою очередь плохо сказывается на файл формируемый CREATE и при заливке портит мне загрузчик. Непонятно как его вообще убрать.

 

Понятно что можно ручками эту строчку из HEX. Но этож будешь забывать. Понятно что потом я BLB поставлю, но хотелось бы найти нормальное решение.

[Сергей Борщ 126]

Так IAR генерит в hex файле по указаному адресу 00000000. Что в свою очередь плохо сказывается на файл формируемый CREATE и при заливке портит мне загрузчик. Непонятно как его вообще убрать.

__no_init const uint32_t __flash SerialNN @ BOOTSERIAL; Но как ты будешь читать серийник, если выставишь локи BLB1? Может лучше разместить в области загрузчика функцию uint16_t SerialNo() { return 0xFFFF; } в которой при прошивке менять 0xFFFF на серийник (AvReal такое умеет)? Она займет на 4 байта больше чем просто константа, но снимет все проблемы.

[SapegoAL 0]

Спасибо, но я не планирую запрещать локи на чтение.

[singlskv 0]

Вчера в 3 часа ночи получил результат 2232. :( Если бы надо было байт 50 выжать ещё бы попытался, а так буду пробовать в обход. Я видишь ли с прерываниями завязался. Возможно придётся отказаться. Только вектора занимают 112 байт. Можно конечно их под себя подмять.

Короче буду думу думать. Жалко выделять 4к если нехватает совсем чуть чуть.

SasaVitebsk, а Вы принципиально не будете пробовать Gcc ?

Стало интересно, посмотрел на исходники, ну этот код, особенно aes.c просто предназначен для

компилирования gcc :)

на Iar там принципиально хуже...

 

P.S. Еще очень порадовало обращение к EEPROM переменным через функции писанные на асм...

Интересно, почему на Iar не воспользовались __eeprom ???

[IgorKossak 0]

__no_init const uint32_t __flash SerialNN @ BOOTSERIAL;

Разве __no_init и __flash совместимы?

[SapegoAL 0]

2 singlskv. Не планирую переходить на GCC. Работы завались и времени на изучение новых пакетов банально не хватает. Тем более, что я пробовал с ним работать вначале. Мне не понравилось, что по сути это не один продукт а десятки слабоинтегрированных фичей. Я, безусловно, не претендую даже на коментарии к этому продукту. Просто высказываю своё первое впечатление. Я уже обратил внимание, что есть специалисты, которым такое построение нравится. Они берут компилятор с одного источника линкер с другого, редактор с третьего а отладчик с четвёртого. Наверное это правильно. Возможно я до этого дойду, но пока - не готов. __eeprom пользуюсь. Ассемблерный файл spm выкинул и пользуюсь IARовскими приблудами. Благо Сергей Борщ предложил свой вариант. Спасибо ему.

 

Кто-нибудь прогу по расчёту CRC от IAR смог повторить? Что-то у меня в лоб не заработало, а подбирать на CRC - гиблый номер. Легче свою сварганить.

 

 

Я пробовал так. Вроде именно так они рекомендуют. Не причёсывал. Чтобы максимально близко к данному варианту было. Потом перепишу.

#define        POLY    0x11021

inline unsigned long
crc16(int bit, unsigned long oldcrc)
{
unsigned long newcrc = (oldcrc << 1) ^ bit;
if (oldcrc & 0x80000000)
newcrc ^= POLY;
return newcrc;
}

__C_task void main(void)
{
  __disable_interrupt();

  #ifdef CRC_CHECK
    // Считаем CRC всей памяти флэш
    unsigned long crc = 0;
    unsigned char i,j;
    unsigned char APPFLASH *p = (unsigned char APPFLASH *)0x000000;
    unsigned char APPFLASH *n = (unsigned char APPFLASH *)MEM_SIZE;
    
    do
    {
      j= *p++;
      for(i=0;i<8;i++)
      {
        crc = crc16(j & 1,crc);
        j>>=1;
      }
    }
    while (--n);
    
    // Если секция программ повреждена
    // то переходим к загрузке в бутлоадер
    if (crc)  ((void (*)())loader)();            // Переходим на сам загрузчик
  #endif
        
  ((void (*)())0x0000)();                        // Если с CRC всё нормально, то перейдём в начало
                                                  // секции программ
}

[Сергей Борщ 126]

Стало интересно, посмотрел на исходники, ну этот код, особенно aes.c просто предназначен для компилирования gcc :)

Ну так а что на "посмотрел" остановились? Попробуйте откомпилировать gcc, увидите, что без основательной "правки напильником" gcc дает в полтора раза бОльший код. И максимальная разница как раз на aes.c.

 

 

#define        POLY    0x11021

0x80000000 великовато. Должно быть что-то около 0x10000. Попробуй такой вариант:

/*
uint16_t CRC (uint16_t crc, uint8_t data) 
{
    static const unsigned short crcPoly = 0x1021;
    crc ^= (uint16_t)data << 8;
    for(uint8_t i = 0; i < 8; i++) 
    {
        if ( crc & (1<<15) ) { crc <<= 1; crc ^= crcPoly; }
        else crc <<= 1;
    }
    return crc;
}
*/

uint16_t CRC(uint16_t crc, uint8_t data) 
{
    static const unsigned short crcPoly = 0x1021;
    
    uint32_t m = ((uint32_t)crc << 8) | data;
    for (uint8_t i = 0; i < 8; i++)
        if ((m <<= 1) & 0x1000000)
            m ^= ((uint32_t)crcPoly << 8);

    return (uint16_t)(m >> 8);
}

Первый вариант эффективнее на 8/16-битной архитектуре, второй - на 32-битной. Считает сразу весь байт.

[singlskv 0]

__eeprom пользуюсь. Ассемблерный файл spm выкинул и пользуюсь IARовскими приблудами. Благо Сергей Борщ предложил свой вариант. Спасибо ему.

Ну если Вы так оптимизируете свой код, то в 2K точно будет сложно влезть...

Кто-нибудь прогу по расчёту CRC от IAR смог повторить? Что-то у меня в лоб не заработало, а подбирать на CRC - гиблый номер. Легче свою сварганить.

По расчету CRC16 опять же гляньте как это реализованно в Gcc,

там есть встроенная функция тактов на 40 (по длинне правда с циклом не сравнивал, меня

скорость обычно больше волнует).

 

 

 

Ну так а что на "посмотрел" остановились? Попробуйте откомпилировать gcc, увидите, что без основательной "правки напильником" gcc дает в полтора раза бОльший код. И максимальная разница как раз на aes.c.

Кто бы спорил ?

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

еще ни о чем не говорит.

Я говорил лишь о том что данный алгоритм больше подходит для Gcc, и Ваш пост:

Да. Проц - мега8. ключ 256 бит. компилятор - 4.10B. Объем кода - 1974, но есть куда ужимать. Та же мега8, WinAVR, 1888, но другой протокол команды входа в программирование и сильное ужимание.

косвенно это подтверждает.

[zltigo 1]

то что Iar справился соптимизировать этот код лучше,

еще ни о чем не говорит.

Я говорил лишь о том что данный алгоритм больше подходит для Gcc...

Т.е. IAR даже "алгоритм больше подхоящий для GCC" скомпилировал лучше :). Но это "ни о чем не говорит" :(. Жаль :)