[MPetrovich 3]

Всем здравствовать.

Разбираюсь сейчас с BSL по UART для прошивки МК MSP430FR5969. В "MSP430™ FRAM Devices Bootloader (BSL) User Guide" описывается структура команд для коммуникации по UART с МК в режиме  BSL. В конце каждой посылки есть два байта CRC-CCITT, которые считаются для всех пересылаемых байт + команда. Например команда смены будрейта выглядит так: 

header    Length   Length   CMD     D1       CKL      CKH

  0x80       0x02      0x00     0x52  0x06     0x14     0x15 

Длина посылки 2 байта(CMD+D1); CRC=0х1514(CKL+CKH)

Я пытаюсь проверить CRC на калькуляторе: https://www.lddgo.net/en/encrypt/crc, но у меня результат не совпадает. В чём проблема не могу понять?

И вообще, насколько необходим этот CRC? В том же документе сказано, что при компиляции в IAR текстовый файл в формате .msp430-txt и залить его по UART. Файл действительно представляет из себя обрезанный .hex без адресов(только начальный), типов посылки и без CRC. 

[_pv 52]

CRC-CCITT-FALSE (с начальным значением 0xFFFF), и без первых трёх байт, начиная с CMD.

[MPetrovich 3]

4 hours ago, _pv said:

CRC-CCITT-FALSE (с начальным значением 0xFFFF), и без первых трёх байт, начиная с CMD.

Не совсем понял что Вы написали. Имеется в виду, что CRC неправильный для CMD+D? Так я о том и говорю. Или вы имеете в виду, что 0х1514 - это 1неверный CRC?

 

[_pv 52]

crc верный, у BSL команд CRC не считается от заголовка и длины, только самой комадны и данных, и начальное значение должно быть 0xFFFF,

то есть если на вышеуказанном сайте выбрать  CRC-CCITT-FALSE и посчитать CRC от 0x52  0x06  контрольная сумма совпадает, получится как раз 0х1514. то есть 0х14 0х15, если ногами вперёд.

и для прошивки CRC проверяется отдельно, там вроде есть отдельная команда для этого.

[MPetrovich 3]

Да, так и есть. Спасибо за подсказку!

А что за CRC-CCITT-FALT? У него отличие от алгоритма CRC-CCITT в чём состоит? Только в том, что инициируется значением 0хFFFF? Вопрос связан с тем, что я реализую загрузчик на AVR и там есть библиотечная функция для CRC-CCITT. Поэтому, если алгоритм тот же, то надо всего лишь указать при объявлении переменной: CRC=0xFFFF. 

[_pv 52]

https://github.com/MSP-EricLoeffler/MSPBSL_Library/blob/7b322eaa31564424746581b90af2f2b5ff193b10/Utility_Classes/MSPBSL_CRCEngine.cpp#L118

[MPetrovich 3]

22 hours ago, _pv said:

https://github.com/MSP-EricLoeffler/MSPBSL_Library/blob/7b322eaa31564424746581b90af2f2b5ff193b10/Utility_Classes/MSPBSL_CRCEngine.cpp#L1118

Это С++? Просто я не очень силён в нём) И потом там есть в начале библиотечный файл: #include "MSPBSL_CRCEngine.h", который непонятно откуда берётся. 

Но всё равно спасибо за ссылку. В общих чертах можно понять процедуру.

А всё же, библиотечный файл AVR для CRC_CCITT не подойдёт?

[_pv 52]

MSPBSL_CRCEngine.h лежит в этой же папке, в нём ничего кроме объявления функций нету

контрольная сумма там вычисляется в тех 3 строчках на которые ссылка, они вполне понятные даже С компилятору без каких-либо плюсов.

https://godbolt.org/z/5TP48cM5h

3 hours ago, MPetrovich said:

А всё же, библиотечный файл AVR для CRC_CCITT не подойдёт?

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

[MPetrovich 3]

On 2/12/2023 at 3:09 AM, _pv said:

On 2/11/2023 at 11:12 PM, MPetrovich said:

А всё же, библиотечный файл AVR для CRC_CCITT не подойдёт?

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

Не подходит библиотечный файл AVR. Вычисляет неправильно.

Нашёл правильную процедуру uint16_t _crc_xmodem_update (uint16_t crc, uint8_t data)вот тут: https://manpages.debian.org/bullseye/avr-libc/_crc_ccitt_update.3avr.en.html

Оказалось, что это crc_xmodem. Не догадался бы ни за что!))). Теперь считает верно, но вылезла другая проблема никак не связанная с CRC. О ней в другой теме напишу...

Спасибо за помощь!