BootLoader, Newbee наступает с вопросами! Опции

[Злодей]

Здравствуйте, ребята!

Написал бутлоадер, написал пользовательскую программу. Оба в WinAVR. Есть в результате два .elf (ну или просто два сишника с main), теперь надо их соединить, да ещё так, чтоб бутлоадер попадал в "Boot Loader Flash Section".
Направьте меня, в какую сторону копать. Есть ли что-то в MakeFile's, что должно быть подправлено?

Ещё есть несколько конкретных впросов:

В даташите на мегу уделено много внимания "Read-While-Write Section" и "No Read-While-Write Section", я не очень с ними разобрался, вообще это важно?

Я сомниваюсь при выборе алгоритма обновления прошивки, сейчас в голове такая картина:
1. Пользовательская программа, решив обновиться, произносит заклинание asm{ jmp $3F00 }, где - $3F00 - Boot Loader Flash Section. (хоть это я правильно понял? Начнёт работать бутлоадер?)
2. Бутлоадер обновляет флэш и делает asm{ jmp $02A }, запуская тем самым пользовательскую программу (или она не там?)
Но почему-то хочется сделать всё через перезагрузку, вроде:
1. пользовательская программа ставит в EEPROM флаг "обновиться" и перезагружает МК
2. бутлоадер видит флаг, обновляет, снимает флаг, перезагружает МК
3. бутлоадер видит - флага нет, и запускает пользовательскую программу.
Но есть ли в этом смысл, и будет ли разница между была перезагрузка - не было?

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

Спасибо!

[Dog Pawlowa]

1. Пользовательская программа, решив обновиться, произносит заклинание asm{ jmp $3F00 }, где - $3F00 - Boot Loader Flash Section. (хоть это я правильно понял? ...

Не совсем. Ставите фьюз перехода на бут после сброса и контроллер будет туда переходить по сбросу. Соответственно приложение должно сбрасывать контроллер.
Все остальное тоже не до конца продумано. Обычно бутлоадер должен быть автономным от приложения, т.к. если во время перезаписи флэш выключится питание, вся система может рухнуть.

[Злодей]

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

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

да ещё так, чтоб бутлоадер попадал в "Boot Loader Flash Section".

Делайте загрузчик отдельным приложением. При линковке задайте параметр -Wl,-section-start=.text=адрес, где адрес - начало области загрузчика (в байтах!)

Бутлоадер обновляет флэш и делает asm{ jmp $02A }, запуская тем самым пользовательскую программу (или она не там?)

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

Но почему-то хочется сделать всё через перезагрузку, вроде:

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

[Огурцов]

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

Ух, как сложно и ненадежно. Переход в приложение должен быть выполнен практически сразу после входа в загрузчик (после сброса), тогда голова об инициализации болеть не будет. А сброс, конечно же, выполняется по собаке.

[defunct]

Ух, как сложно и ненадежно. Переход в приложение должен быть выполнен практически сразу после входа в загрузчик (после сброса)

Запускать битый аппликейшн сразу, это похоже ваш стиль... И он должно быть "чертовски" надежен...

Я предпочитаю так:

CODE

/***********************************************
* RunApplication() *
* This routine shuts-off peripherals used *
* by the bootloader and performs jump to 0x0 *
* address *
* *
***********************************************/
void RunApplication(void)
{
V32 tmp = 500000;
pgm_print("trying to run application...\n");
if (brmContext.appChanged)
{
iap_Finalize(); // make sure all flash operations are completed and RWW section re-enabled
// rebuild app section CRC
brmContext.appSectionCRC = iap_CheckCRC();
brmContext.appChanged = FALSE;
}

if (brmContext.appSectionCRC)
{
// Wrong CRC! (section corrupted)
pgm_print("app section CRC error detected, can't leave bootloader\n");
return;
}

while(tmp--); // wait while queues being flushed

cli(); // disable interrupts

// stop timers
ETIMSK = 0; // disable Extended timers int sources
TIMSK = 0; // disable timers int sources

TCCR3B = 0; // stop timer3
TCCR2 = 0; // stop timer2
TCCR1B = 0; // stop timer1
TCCR0 = 0; // stop timer0

// stop uarts
UCSR1B = 0; // stop UART1
UCSR0B = 0; // stop UART0

// stop SPIs
SPCR = 0; // stop SPI0

// stop TWI bus
TWCR = 0; // stop TWI module

// reset used ports
DDRF = 0;
PORTF = 0;

DDRE = 0;
PORTE = 0;

DDRB = 0;
PORTB = 0;

// switch interrupt vector table to app section
MCUCR = (1 << IVCE);
MCUCR = (0 << IVSEL);

// jump to zero address
((void(*)(void))0x0)();
}

[Огурцов]

Запускать битый аппликейшн сразу, это похоже ваш стиль... И он должно быть "чертовски" надежен...

Я этого не говорил, речь идет про недопустимую инициализацию железа в загрузчике между ресетом и переходом в приложение.

Я предпочитаю так

Вот-вот, именно так и не надо.

[Злодей]

Спасибо за советы, я скопирую сюда уже тысячу раз сказанное "Bootloader - как сделать?" - прочитать апноут atmel 109, даташит на МК, WinAVR/doc/avr-libc/avr-libc-user-manual/boot_8h.html все вопросы отпадают.

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

Я этого не говорил, речь идет про недопустимую инициализацию железа в загрузчике между ресетом и переходом в приложение.

AT91SAM7 стартует от RC на 32КГц. Приложение может быть до 512К (минус загрузчик). Вы представляете, сколько времени займет подсчет целостности этого приложения при 32КГц тактовой? Разрешите хоть PLL включить, а? У MSP430 после включения питания запущена собака. Если ее не отключить, через 32768 тактов она сбросит процессор. Разрешите отключить ее на время проверки целостности? defunct выводит диагностические сообщения в консоль. Разрешите ему UART настроить, а то не видно ничего? Нужные порты разрешите настроить на вывод, что б не болтались?

[Dog Pawlowa]

Разрешите ...

Если принимать высказывание Огурцова как напоминание, что приложение не должно рассчитывать, что что-то сконфигурировано загрузчиком, то можно придти к консенсусу

[Злодей]

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

Так вроде ни кто не советует проверять перед каждым запуском

[defunct]

Так вроде ни кто не советует проверять перед каждым запуском

Я советую проверять перед каждым запуском. Мало ли какая ситуация случится, например - бутлоадер что-то шил и пропало питание.

[Dog Pawlowa]

Я советую ..

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

[Огурцов]

AT91SAM7 стартует от RC на 32КГц.

Мы про AVR ?

Разрешите хоть PLL включить, а?

Пока используется один программер, один камень и одно приложение, можно делать что попало. Как только чего-то становиться два и более, желательно забыть о допущениях, типа что приложение что-то там знает о загрузчике или загрузчик правильно деинициализируется на всех камнях.

У MSP430 после включения питания запущена собака.

Так AVR и сбрасывается собакой. Все остальное от лукавого. И собаку в загрузчике сбрасывать никто не запрещает.

Разрешите отключить ее на время проверки целостности?

Я не отключаю и не советую.

defunct выводит диагностические сообщения в консоль.

Это режим отладки ? Делайте что попало. Если штатный, то это уже допущение, которое требуется учитывать _всеми_.

Нужные порты разрешите настроить на вывод, что б не болтались?

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

Так вроде ни кто не советует проверять перед каждым запуском

Я советую. Так же как и загрузчик. Так же как и область данных. Так же как и фьюзы.

[defunct]

Есть еще какие-то другие причины инициализировать железо до контроля валидности флеша ?

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

Давайте его перефразируем, чтобы вложить в него смысл:
- Есть еще какие-то другие причины инициализировать железо перед запуском приложения?

Есть конечно же.
Первая и наиболее серьезная причина - влетели в бут нештатным образом (врезультате ошибки основного приложения).

Вторая причина - допустим Bootloader проверил целостность, и с апп - все Ок. Как теперь ему узнать надо обновлять прошивку или не надо?
Без инициализации периферии - никак (аргумент "аппликейшн сообщает" - не катит, т.к. такой подход добавляет зависимость между бутлоадером и приложением).
Итого хоть какую-то периферию проиниализировать надо чтобы принять решение, что буту делать дальше:
1. обновить прошивку;
2. запустить приложение;
3. сделать что-то еще (например провести диагностику железа, отгрузить дамп/статисткику последнего запуска и т.п.).

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

Это режим отладки ? Делайте что попало. Если штатный, то это уже допущение, которое требуется учитывать _всеми_.

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

Выключить периферию так, чтобы от железного сброса было не отличить - дело нехитрое. Насколько это сложно - сами видите, достаточно просто записать 0 в соотв. регистры периферии.

Так AVR и сбрасывается собакой. Все остальное от лукавого.

Резетить контроллер из бутлоадера по WDT после проверки целостности прошивки чтобы запустить app, одним словом называется - дебилизм. Причину назову если спросите. (конечно же вы так не делаете, поэтому это к вам не относится. Только тут у меня возникает вопрос - а как вы запускаете приложение после обновления прошивки, ведь в процессе обновления прошивки вы периферию инициализируете, не так ли?).

И собаку в загрузчике сбрасывать никто не запрещает.

По поводу сбрасывания WDT - тут строго говоря, всегда надо исходить из того, что по законам Мерфи WDT включен и обязательно с минимально возможным интервалом.
А это значит, что в некоторых случаях (низкая тактовая + обновление NRWW) может понадобиться хотя бы изменить его интервал, иначе МК может сброситься при выполнении SPM.