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

Имеется следующая проблема: пытаюсь загружать через 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 в аттаче.

Сообщение отредактировал Vishay - Jun 7 2007, 06:56

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

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

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

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

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

Сообщение отредактировал Vishay - Jun 7 2007, 19:13

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

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

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

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



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



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

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

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

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

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


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

 xmodem.zip ( 52.97 килобайт ) Кол-во скачиваний: 209

С первым своим вопросом разобрался: ошибка была в том, что алгоритм считал 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[attachment=11940:attachment][attachment=11940:attachment]test ) платы проходит нормально.

Ч.д. ?