Ещё раз о бутлоадере, Некоторые тонкости. Опции

[SasaVitebsk]

Задумка такая.

По старту попадаем в бут. Там считаем CRC и если Ok - выходим на саму приложение. Если не Ok то переходим на сам лодырь.

В приложении по команде переходим непосредственно на лоадырь.


То есть мне надо две точки входа. По сбросу и по команде. Хотелось бы использовать незадействованные вектора бутлоадера. Например +2. Как это сделать. Если использовать pragma location, то наверняка будет linker ругаться.

Конечно можно упростить задачу и использовать какой нибудь признак в EEPROM. Или портить CRC к примеру, но что-то мне не нравится такой подход.

А кто как делает?

[SasaVitebsk]

Сергей, всётаки по коду не уложился в 2к. Со своим WakeUp-ом. Там ещё некоторые приколы есть. У меня должно осуществляться обновление прямо в сети. Соответственно при обновлении требуется сверять серийный номер устройства. Его я не хочу записывать в лоадер, дабы лоадер унифицированный был. Поэтому при перепрошивке вытаскиваю номер перепрошиваю и сохраняю номер.

Короче впрямую в 2к не влез. В связи с тем, что сам протокол Wake, если работать ч/з прерывания, практически не связан с лоадером - переписал его на ASM. Думаю так влезу.

Но вот возник вопрос.

там есть конструкция в лоадере если помнишь.

typedef union
{
struct
{
uint8_t m_rxBuffer[BUFFER_SIZE]; // Receive buffer
uint8_t m_pageBuffer[PAGE_SIZE]; // Page is assembled here before
// getting programmed to flash mem
} part1;

#define rxBuffer sharedbufs.part1.m_rxBuffer

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

Но у меня с ней проблемы на ASM. Не могу понять как на ASM указать адрес начала буфера приёмного (rxBuffer)???


Сори. Разобрался.

Просто как-то в голове не укладывается как в ассемблере имена структур фигурируют. Понятно что потом линкер их к адресам приводит, но всё равно несколько диковато.

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

Сергей, всётаки по коду не уложился в 2к. Со своим WakeUp-ом.

Ты пытаешься засунуть в загрузчик еще какие-то команды кроме UpdateFirmware? У меня Wake-подобный протокол, я сделал так:

Код

static unsigned char busReceiveByte(void)
{
    uint8_t c = UART_getchar();
    if(c == CTL)
        c = UART_getchar() ^ 0x20;
    return c;
}
__C_task void main(void)
{
.......
    if(!dir(MANUAL_PROG))
    {
        uint8_t command[7];
        command[0] = 0xC0;          // Begin Of Frame
        uint16_t Tmp = SerialNo();
        command[1] = Tmp;
        command[2] = Tmp >> 8;
        command[3] = 0xFF;
        uint8_t *ptr = &command[1];
        Tmp = 0xFFFF;
        Tmp = CRC_XMODEM (*ptr++, Tmp);
        Tmp = CRC_XMODEM (*ptr++, Tmp);
        Tmp = CRC_XMODEM (*ptr++, Tmp);
        command[4] = ~Tmp;
        command[5] = ~(Tmp >> 8);
        command[6] = 0xC1;          // End Of Frame
        uint8_t idx = 0;
        do {
            uint8_t c = busReceiveByte();

            if(c != command[idx])
                idx = 0;
            else
                idx++;
        } while(idx < sizeof(command));        // wait for EOM
    }
    busReplyByte(ERROR_OK);

Т.е. я формирую образ всей команды и сравниваю проходящий поток с образцом. Сгенерить образец гораздо проще, чем реализовывать весь конечный автомат приема. Увы, это проходит только для одной команды.

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

У меня в области загрузчика есть функция

Код

#pragma segment="GET_SERIAL"
#pragma location="GET_SERIAL"
__root uint16_t SerialNo(void) { return ~0;}

При прошивке я указываю AvRealу -c?serno2=1826,serno.txt и он автоматически при программировании подставляет в эту функцию уникальные номера. Номер хранится в загрузчике и не может быть случайно стерт с приложением. Функцию SerialNo() можно вызвать и из приложения, поэтому и приложение становится независимым от серийника. Функция занимает 6 байт, что меньше чем код для чтения 16-битной константы из флеш с помощью LPM

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

Именно так. Для улучшения читабельности. Т.е. "сейчас мы работаем с этим блоком как с буфером приема"

Сори. Разобрался.
Просто как-то в голове не укладывается как в ассемблере имена структур фигурируют. Понятно что потом линкер их к адресам приводит, но всё равно несколько диковато.

Ну, если не на плюсах писать, то имена как и у обычных переменных. А вот к полям из ассемблера, увы, только вручную указывая смещение от начала структуры.

[SasaVitebsk]

Ты пытаешься засунуть в загрузчик еще какие-то команды кроме UpdateFirmware? У меня Wake-подобный протокол, я сделал так:

Пытаюсь Сергей.

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

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


Спасибо за рекомендации. Разбираюсь. Пользуюсь. Помагает.

[singlskv]

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

SasaVitebsk, а Вы принципиально не будете пробовать Gcc ?
Стало интересно, посмотрел на исходники, ну этот код, особенно aes.c просто предназначен для
компилирования gcc
на Iar там принципиально хуже...

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