Форум разработчиков электроники ELECTRONIX.ru

Vishay

Jun 7 2007, 06:53

Доброго времени суток.

Имеется следующая проблема: пытаюсь загружать через DBGU файл romboot.bin по xmodem'у в процессор AT91RM9200 с помощью Hypertrminal'a.
Загрузка проходит успешно, romboot запускается, но при попытке записи romboot'a в DataFlash командой "1 C0000000" Hyperterminal выдает сообщение "Превышен предел по числу ошибок" и ничего в AT91RM9200 не загружает. При этом, если грузить вместо romboot.bin файл из одних нулей, то загрузка производится нормально, в осциллограф видна активность на SPI- интерфейсе DataFlash ( правда запись в DataFlash неуспешна, но это уже другая история -

)
Перехватом передачи от PC к DBGU AT91RM9200 выяснено, что CRC16 для тестового блока данных
"12345678" (ASCII строка), используемая для тестирования алгоритмов подсчета CRC, равна D053h,
что никак не вяжется с тем, что считает, например, калькулятор CRC On-line CRC calculation and free library http://www.lammertbies.nl/comm/info/crc-ca...mp;method=ascii

Вопрос первый: по какому алгоритму считает CRC16 Hyperterminal для протокола Xmodem ?

Вопрос второй: где в исходниках romboot'а определено, по какому из трех возможных встроенных в AT91RM9200 алгоритмов CRC16 Embedding Service он ( romboot ) будет считать CRC16 ? Есть подозрение, что после запуска romboot и запуска начала записи в Dataflash, romboot переключается на другой,чем первоначально использовал AT91RM9200 после reset'a, алгоритм подсчета CRC16 для xmodem - протокола.

P.S. Перехваченные фрагменты общения hyperterminal'a c AT91RM9200 через DBGU в аттаче.

KRS

Jun 7 2007, 11:11

Вообще в xmodem CRC можно считать такой функцией

Код

uint_fast16_t x_update_crc(uint_fast16_t  crc,
                           uint_fast8_t  c
)
{
    crc  = (crc >> 8) | (crc << 8);
    crc ^= c;
    crc ^= (unsigned char)(crc & 0xff) >> 4;
    crc ^= (crc << 8) << 4;
    crc ^= ((crc & 0xff) << 4) << 1;
    return crc & 0xffff;
}

lebiga

Jun 7 2007, 18:27

У тебя CRC состоит из 2 байт - это скорее модификация XModema!

"Протокол XModem-CRC представляет собой модификацию протокола XModem, в котором обнаружение ошибок производится с использованием циклического кода. Длина проверочной последовательности составляет 16 бит (CRC-16). Благодаря этому гарантируется обнаружение практически всех одиночных и двойных ошибок, всех нечетных ошибок, всех пакетов ошибок длиной до 16 знаков, а также всех 17-битовых ошибок с вероятностью 0,999969 и более длинных пакетов ошибок с вероятностью 0,999984.

В начале соединения вместо знака NAK приемник передает последовательность знаков "с" (63h). Если передатчик не поддерживает протокол XModem-CRC, он игнорирует эти знаки. Не получив ответа на передачу трех знаков "с", приемник переходит на работу по протоколу XModem и передает знаки NAK. "

Vishay

Jun 7 2007, 19:10

Цитата(KRS @ Jun 7 2007, 14:11)

Вообще в xmodem CRC можно считать такой функцией

Код

uint_fast16_t x_update_crc(uint_fast16_t  crc,
                           uint_fast8_t  c
)
{
    crc  = (crc >> 8) | (crc << 8);
    crc ^= c;
    crc ^= (unsigned char)(crc & 0xff) >> 4;
    crc ^= (crc << 8) << 4;
    crc ^= ((crc & 0xff) << 4) << 1;
    return crc & 0xffff;
}

Проверил работу Вашей функции - на тестовой строке "123456789" она дает результат 31С3 (если начальное значение crc=0, а судя по логам здесь без вариантов), как и написано в учебниках, а hyperterminal посылает процессору AT91RM9200 CRC=0xD053 и он на это отвечает кодом 0x06, а на 31С3 кодом 0x15. Так что это вроде как не подходит -

.

lebiga

Jun 7 2007, 19:30

Цитата(Vishay @ Jun 7 2007, 23:10)

Проверил работу Вашей функции - на тестовой строке "123456789" она дает результат 31С3 (если начальное значение crc=0, а судя по логам здесь без вариантов), как и написано в учебниках, а hyperterminal посылает процессору AT91RM9200 CRC=0xD053 и он на это отвечает кодом 0x06, а на 31С3 кодом 0x15. Так что это вроде как не подходит -

.

Посмотри http://faqs.org.ru/progr/common/crc_faq.htm

Vishay

Jun 8 2007, 05:42

Цитата(lebiga @ Jun 7 2007, 22:30)

Посмотри http://faqs.org.ru/progr/common/crc_faq.htm

Посмотрел вашу ссылку, но по моему конкретному вопросу ничего полезного не обнаружил.

KRS

Jun 8 2007, 13:43

Цитата(Vishay @ Jun 7 2007, 23:10)

Проверил работу Вашей функции - на тестовой строке "123456789" она дает результат 31С3 (если начальное значение crc=0, а судя по логам здесь без вариантов), как и написано в учебниках, а hyperterminal посылает процессору AT91RM9200 CRC=0xD053 и он на это отвечает кодом 0x06, а на 31С3 кодом 0x15. Так что это вроде как не подходит -

.

Если вы почитаете описание XMODEM, то увидите что данные передаются блоками исключительно по 128 байт. И стандартно остаток заполняется 0x1A. У вас почемуто глюкотерминал заполнил 0 и получилось строка 123456789 и 119 символов с кодом 0 и соотв CRC получатеся 0xD053, хотя по стандарту нужно заполнять 0x1A и CRC получается 0xE447.
К тому же если вы не увидели в логе 00 то у вас еще и глючная программа пишет логи.

MALLOY2

Jun 11 2007, 13:58

Вот такая у меня используется процедурка для подсчета CRC, работает 100% так как у меня по XMODEMу конфигурируется FPGA.

Код

unsigned short xmodem_crc_update(unsigned short crc, char data)
{
    int i;
    crc = crc ^ ((unsigned short)data << 8);
    for (i=0; i<8; i++)
    {
     if(crc & 0x8000) crc = (crc << 1) ^ 0x1021;
     else                crc <<= 1;
    }
    return(crc);
}

Еще не стоит забывать про порядок байтов, у XMODEMа используетсяф big-endian а большинство процов работают в little-endian в итоге у меня получилось типа этого

Код

      crc = 0;
      ptr = (unsigned char*)data->data;
      for (i=0;i<XMODEM_DATA_SIZE;i++)
       {
        crc = xmodem_crc_update(crc,*ptr++);
       };
      crc_rcv  = data->CRC >>8;
      crc_rcv |= data->CRC <<8;
      if (crc == crc_rcv)  ......

P.S. У XMODEMа CRC считается только на данные, тоесть заголовок не считается.

KRS

Jun 11 2007, 14:57

Цитата(MALLOY2 @ Jun 11 2007, 17:58)

Вот такая у меня используется процедурка для подсчета CRC, работает 100% так как у меня по XMODEMу конфигурируется FPGA.

Код

unsigned short xmodem_crc_update(unsigned short crc, char data)
{
    int i;
    crc = crc ^ ((unsigned short)data << 8);
    for (i=0; i<8; i++)
    {
     if(crc & 0x8000) crc = (crc << 1) ^ 0x1021;
     else                crc <<= 1;
    }
    return(crc);
}

Гораздо эффективнее использовать такую функцию, в ней нет циклов и переходов

Код

uint_fast16_t x_update_crc(uint_fast16_t  crc,
                           uint_fast8_t  c
)
{
    crc  = (crc >> 8) | (crc << 8);
    crc ^= c;
    crc ^= (unsigned char)(crc & 0xff) >> 4;
    crc ^= (crc << 8) << 4;
    crc ^= ((crc & 0xff) << 4) << 1;
    return crc & 0xffff;
}

MALLOY2

Jun 11 2007, 15:32

Код

crc = (crc >> 8) | (crc << 8);

- Это в иаре не работает.

Код

return crc & 0xffff;

- А зачем анд здесь ? это бессмысленная операция.

KRS

Jun 11 2007, 16:43

Цитата(MALLOY2 @ Jun 11 2007, 19:32)

Код

crc = (crc >> 8) | (crc << 8);

- Это в иаре не работает.

Прекрасно работает. Я именно IAR и использовал, этот код работает на ARM.

Цитата(MALLOY2 @ Jun 11 2007, 19:32)

Код

return crc & 0xffff;

- А зачем анд здесь ? это бессмысленная операция.

например на ARM uint_fast16_t - 32 битный тип, поэтому надо чистить старшие биты.
на intel тоже имеет сысл использовать 32 разрядные переменные, они просто напросто быстрее!

Vishay

Jun 15 2007, 10:35

Нажмите для просмотра прикрепленного файла
С первым своим вопросом разобрался: ошибка была в том, что алгоритм считал CRC до первого бинарного нуля в массиве, а надо было по всему блоку данных. Кому интересно, в аттаче проект консольного приложения MS VC6 для загрузки и управления romboot'ом, а также бинарный файл hello.bin, который при кварце 18,432 МГц раз в секунду выдает через DBGU фразу "Hello world" и мигает светодиодом на линии PB27 (BL_COMPLETE ) независимо от номинала кварца.

Со вторым своим вопросом ( по поводу записи данных через xmodem romboot'ом в DataFlash ) все на том же месте: на любые CRC, посчитанные на PC при помощи lib_crc.c процессор отвечает кодом 0x15 (NACK ).

P.S. Тест SDRAM ( gcc_memНажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файлаtest ) платы проходит нормально.

Ч.д. ?