Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: загрузчик по USB для at91sam7s256
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
romez777
Приветствую.

Разбираюсь с at91, пишу простой бутлоадер по USB (без криптографии и пр.). Драйвер для USB - CDC, пример с сайта работает вполне исправно, слегка подточил для себя.

Атмеловскую доку почитал, но пока пребываю в конфузии smile.gif

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

Заранее благодарю за советы и замечания.
KAlex
Цитата(romez777 @ Apr 3 2008, 14:53) *
1) Нужно написать простое приложение со стороны хоста (Windows) для загрузки образа на флеш - не совсем понимаю, как правильно порезать образ на равные блоки (вроде документация советует всегда записывать страницами?)

Из PC лучше слать блоками по 64. Бут собирает два блока и заливает страницу.

Цитата(romez777 @ Apr 3 2008, 14:53) *
2) со стороны бутлоадера как определить, что текущий блок последний (с тем чтобы после его записи передать управление на залитое во флеш приложение). Нужно ли каждый блок предварять каким-то хедером?

Перед началом в бут передается размер прошивки.
Хедер не обязательно, а вот CRC было бы неплохо.
romez777
Цитата(KAlex @ Apr 3 2008, 15:20) *
Из PC лучше слать блоками по 64. Бут собирает два блока и заливает страницу.


По 64 байта? А почему не сразу страницей, т.е. 256 байт, чем такой подход лучше?

Цитата
Перед началом в бут передается размер прошивки.
Хедер не обязательно, а вот CRC было бы неплохо.


Но размер всей прошивки не позволит выяснить окончание передачи всего образа?
aaarrr
Цитата(romez777 @ Apr 4 2008, 04:05) *
По 64 байта? А почему не сразу страницей, т.е. 256 байт, чем такой подход лучше?

Для RS232 такой подход был бы лучше, для USB CDC я бы рекомендовал использовать большие пакеты (1-2 страницы).

Цитата(romez777 @ Apr 4 2008, 04:05) *
Но размер всей прошивки не позволит выяснить окончание передачи всего образа?

То есть как? Вычитаем из общего размера длину каждого полученного пакета, если 0 - конец передачи.

А вообще лучше сделать простенький командный интерфейс, чтобы PC говорил устройству, что делать: грузить/читать данные, запустить приложение и т.п.
romez777
Цитата(aaarrr @ Apr 4 2008, 09:11) *
То есть как? Вычитаем из общего размера длину каждого полученного пакета, если 0 - конец передачи.


что-то я все равно не догоняю sad.gif
Предположим размер образа 5088 байт. Пилим его на куски по 256 байт (это размер страницы для at91sam7s256), получаем 19 частей по 256 байт и 1 кусок размером 224 байта.

Как здесь может помочь Ваш подход?

Цитата
А вообще лучше сделать простенький командный интерфейс, чтобы PC говорил устройству, что делать: грузить/читать данные, запустить приложение и т.п.


для начала реализую что-то простое, чтобы просто работало, а потом буду добавлять фичи.
aaarrr
Цитата(romez777 @ Apr 4 2008, 11:37) *
что-то я все равно не догоняю sad.gif
Предположим размер образа 5088 байт. Пилим его на куски по 256 байт (это размер страницы для at91sam7s256), получаем 19 частей по 256 байт и 1 кусок размером 224 байта.

1. Говорим загрузчику на кристалле: размер образа L=5088 байт.
2. Передаем 19 пакетов по 256 байт. Загрузчик вычитает размер пакета из размера образа (L=5088, L=4832, L=4576...L=224)
3. Передаем последний пакет 224 байта. В этот момент L=0, передача закончена.
romez777
Цитата(aaarrr @ Apr 4 2008, 10:43) *
1. Говорим загрузчику на кристалле: размер образа L=5088 байт.
2. Передаем 19 пакетов по 256 байт. Загрузчик вычитает размер пакета из размера образа (L=5088, L=4832, L=4576...L=224)
3. Передаем последний пакет 224 байта. В этот момент L=0, передача закончена.


Приветствую.

Я так и подумал, но тогда нужно передавать и размер пакета? Ведь принимаемый по USB буфер может быть бОльшего размера, например, 300 байт.
Сорри за глупые вопросы smile.gif я только разбираюсь.
aaarrr
Размер и так будет известен, но лучше снабдить каждый пакет хидером, где будет указано:
1. Что это за пакет (код команды)
2. Его длина
3. и т.п.
То есть сделать свой простенький протокол обмена.
romez777
Ага, таки хедер нужен - туда же можно и CRC поместить.

Цитата(aaarrr @ Apr 4 2008, 14:22) *
Размер и так будет известен, но лучше снабдить каждый пакет хидером, где будет указано:
1. Что это за пакет (код команды)


То есть здесь можно передавать команды - например, запись страницы, чтение, запуск и пр. ? Т.е. простой командный интерфейс.

Спасибо, сейчас перспектива намного яснее!

Цитата
2. Его длина
3. и т.п.
То есть сделать свой простенький протокол обмена.
romez777
Еще такой вопрос: приложение, которое будет загружаться бутлоадером, должно быть откомпилировано и слинковано как-то особенным образом или обычным? Где-то читал, что вроде советуют первые N байт заполнять нулями, для этого в IAR есть выходной формат mpds-code. Или я не так понял? smile.gif

Спасибо!
aaarrr
Приложение должно быть собрано и слинковано:
1. Для старта с соответсвующего адреса
2. Со своим startup'ом, учитывающим наличие bootloader'а

По-хорошему, это задача загрузчика передать основной программе процессор в наиболее приближенном к исходному состоянию виде, что, к сожалению, далеко не всегда возможно.
romez777
Цитата
Приложение должно быть собрано и слинковано:
1. Для старта с соответсвующего адреса
2. Со своим startup'ом, учитывающим наличие bootloader'а


Вот в этом документе http://atmel.com/dyn/resources/prod_documents/doc6282.pdf посвященном бутлоадеру, почему-то ничего не сказано про то, как учитывать наличие бута из приложения sad.gif

Что должно содержаться в C-startup'e приложения (ведь о нем речь?) - таблица векторов, объявленная в коде бутлоадера? Или может быть есть где-то почитать об этом?

Цитата
По-хорошему, это задача загрузчика передать основной программе процессор в наиболее приближенном к исходному состоянию виде, что, к сожалению, далеко не всегда возможно.
aaarrr
С таблицей векторов в случае SAM7 все достаточно прозрачно - можно сделать remap и расположить её в RAM, или использовать ту же таблицу, что и bootloader.

В самом загрузчике перед передачей управления следует сбросить использованную периферию и запретить прерывания.
romez777
Цитата(aaarrr @ Apr 5 2008, 15:38) *
В самом загрузчике перед передачей управления следует сбросить использованную периферию и запретить прерывания.


А в вызываемом приложении потом включать прерывания? А с чем связана необходимость отключать прерывания на момент передачи управления?

Спасибо.
aaarrr
Цитата(romez777 @ Apr 5 2008, 17:10) *
А в вызываемом приложении потом включать прерывания?

Да.
Цитата(romez777 @ Apr 5 2008, 17:10) *
А с чем связана необходимость отключать прерывания на момент передачи управления?

Вероятностью улететь из приложения в неизвестном направлении.
romez777
Цитата(aaarrr @ Apr 5 2008, 16:17) *
Да.

Вероятностью улететь из приложения в неизвестном направлении.


Вероятно, с этим связано моя проблема, описанная здесь:
http://electronix.ru/forum/index.php?showt...pid=392203&
romez777
Здравствуйте,

Цитата(aaarrr @ Apr 5 2008, 15:38) *
С таблицей векторов в случае SAM7 все достаточно прозрачно - можно сделать remap и расположить её в RAM, или использовать ту же таблицу, что и bootloader.

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


наверное я что-то делаю неправильно smile.gif потому как не работает должным образом.

Вот так отключаю прерывания и сбрасываю процессор и периферию в бутлоадере ПЕРЕД передачей управления (пропустил инклюды и пр. для экономии места):
Код
typedef void (*funct)(void);

//* external functions
extern unsigned disableIRQ();

...

int main(void)
{
    AT91F_DBGU_Init();
    AT91F_DBGU_Printk("before jump\n\r");

    //Run the application
    ((funct)0x10058c)();

    disableIRQ();
    *AT91C_RSTC_RCR = 0xa500000d;    //Reset device
}


А вот здесь я получаю управление и включаю прерывания:
Код
//* external functions
extern unsigned enableIRQ();
...

int main(void)
{
   enableIRQ();

   AT91F_DBGU_Init();
   AT91F_DBGU_Printk("after jump\n\r");

   while (1)
   {
   }
}


Вот функции disableIRQ и enableIRQ:
Код
#define IRQ_MASK 0x00000080

static inline unsigned __get_cpsr(void)
{
    unsigned long retval;
    asm volatile (" mrs  %0, cpsr" : "=r" (retval) : /* no inputs */  );
    return retval;
}

static inline void __set_cpsr(unsigned val)
{
    asm volatile (" msr  cpsr, %0" : /* no outputs */ : "r" (val)  );
}

unsigned disableIRQ(void)
{
    unsigned _cpsr;
    _cpsr = __get_cpsr();
    __set_cpsr(_cpsr | IRQ_MASK);
    return _cpsr;
}

unsigned enableIRQ(void)
{
    unsigned _cpsr;

    _cpsr = __get_cpsr();
    __set_cpsr(_cpsr & ~IRQ_MASK);
    return _cpsr;
}


Все компилируется успешно, загружаю в флеш. На всякий случай проверяю SAM-BA, что образы находятся по нужным адресам (все корректно), запускаю: работает нестабильно, иногда печатается before jump, потом after jump (то есть переход происходит), а иногда в момент перехода на второей образ сыпется мусор. После пересброса платы все повторяется.

Что я делаю не так?

Благодарю за помощь!

PS. на всякий случай прикрепляю ld-скрипты.

Первое приложение, размер 1420 байт (0x58c):
Код
/* Memory Definitions */
MEMORY
{
  CODE (rx) : ORIGIN = 0x00100000, LENGTH = 0x00040000
  DATA (rw) : ORIGIN = 0x00200000, LENGTH = 0x00010000
  STACK (rw) : ORIGIN = 0x00204000,LENGTH = 0x00000000
}
...


Второе приложение (на которое передается управление):
Код
/* Memory Definitions */
MEMORY
{
  CODE (rx) : ORIGIN = 0x0010058c, LENGTH = 0x00040000
  DATA (rw) : ORIGIN = 0x00200000, LENGTH = 0x00010000
  STACK (rw) : ORIGIN = 0x00204000,LENGTH = 0x00000000
}

...
// все остальное по умолчанию
aaarrr
Цитата(romez777 @ Apr 7 2008, 05:12) *
...
Вот так отключаю прерывания и сбрасываю процессор и периферию в бутлоадере ПЕРЕД передачей управления (пропустил инклюды и пр. для экономии места):
Код
typedef void (*funct)(void);

//* external functions
extern unsigned disableIRQ();

...

int main(void)
{
    AT91F_DBGU_Init();
    AT91F_DBGU_Printk("before jump\n\r");

    //Run the application
    ((funct)0x10058c)();

    disableIRQ();
    *AT91C_RSTC_RCR = 0xa500000d;    //Reset device
}

А в исходнике они отключаются ПОСЛЕ.
Это -
Код
*AT91C_RSTC_RCR = 0xa500000d;    //Reset device

- сбросит вообще все, а не только периферию.

Симулятором пройдитесь - может что прояснится.
romez777
Цитата(aaarrr @ Apr 7 2008, 08:18) *
А в исходнике они отключаются ПОСЛЕ.
Это -
Код
*AT91C_RSTC_RCR = 0xa500000d;    //Reset device

- сбросит вообще все, а не только периферию.


Переделал:
Код
disableIRQ();
*AT91C_RSTC_RCR = 0xa5000004;  // reset only peripherals

((funct)0x10058c)();


Не помогает, такое впечатление, что вообще не передает управление.

Цитата
Симулятором пройдитесь - может что прояснится.

О каком симуляторе речь? У меня Gnu-ARM тулчейн, в комплекте ничего похожего на симулятор нет.
aaarrr
Цитата(romez777 @ Apr 7 2008, 10:09) *
О каком симуляторе речь? У меня Gnu-ARM тулчейн, в комплекте ничего похожего на симулятор нет.

Печально. Ну, подсуньте бинарник симулятору из какого-нибудь другого пакета.
KAlex
Цитата(romez777 @ Apr 5 2008, 16:10) *
А с чем связана необходимость отключать прерывания на момент передачи управления?

Ну на момент передачи управления может и не надо, а вот на момент записи во флеш точно необходимо.
romez777
Цитата(KAlex @ Apr 7 2008, 10:57) *
Ну на момент передачи управления может и не надо, а вот на момент записи во флеш точно необходимо.


Гм.. интересно, почему в атмеловской библиотеке по работе с флешем, отключения прерываний нет?
aaarrr
Цитата(KAlex @ Apr 7 2008, 11:57) *
Ну на момент передачи управления может и не надо, а вот на момент записи во флеш точно необходимо.

Точно необходимо только если может случиться чтение из flash в момент записи. Если программа и вектора прерываний находятся в RAM, то прерывания можно не запрещать.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.