srec_cat: test.hex: 3: warning: data records not in strictly ascending order (expected >= 0x300020, got 0x300010) srec_cat: test.hex: 3: multiple 0x00300010 values (previous = 0x76, this one = 0x29)
Пытался перевести hex-файл - в bin утилитой srec_cat .. как правильно указать утилите ключи, чтобы в этом случае она отрабатывала правильно?
За вашу утилиту не скажу, доводилось пользоваться hex2bin, проблем не возникало (и на 7/64 и на 10/64) Ссылочка на страничку https://sourceforge.net/projects/hex2bin/
[uquote="jockerface" Вот начало этого файла: [code]:020000040030CA :20000000761BFFF0E20000BDE63006002942561676256F00761BFFF0E20000BDE630060089 :200010002942561676256F00761BFFF0E20000BDE63006002942561676256F00761BFFF053 :20002000E20000BDE63006002942561676256F00761BFFF0E20000BDE63006002942561612 :2000300076256F00761BFFF0E20000BDE63006002942561676256F00761BFFF0E20000BD6B[/code/] [/uquote] Стесняюсь спросить, а Вы формат .hex смотрели? Сгенерировано неправильно. В строке кода декларировано 32 байта (0x20)кода, а адрес инкрементируется на 16 байт (010). Вот у преобразователя башню и клинит. Шаг адреса должен быть 0х20. Ну или по 16 байт в строке.
Сгенерировано неправильно. В строке кода декларировано 32 байта (0x20)кода, а адрес инкрементируется на 16 байт (010). Вот у преобразователя башню и клинит. Шаг адреса должен быть 0х20. Ну или по 16 байт в строке.
Так сгенерировано думаю потому, что автор работает с DSP, у которых размер слова = 16 бит и никаких байтов такие DSP не знают. О чём автор конечно же "забыл" упомянуть. Адресация в таких DSP идёт словами, поэтому шаг адреса - правильный, так как каждый адрес содержит 16 бит данных.
Насчёт "на кой нужно переводить" - присоединяюсь к предыдущим ораторам. На кой??? Работайте с hex-файлом. Это и удобнее и идеологически правильнее.
Насколько помню - в тех DSP, в которых адресное пространство измеряется словами (семейство C5000 TI DSP), чиповый ROM-загрузчик принимает двоичный образ. Что конечно же нисколько не мешает читать .hex-файл, а отправлять в DSP - бинарный образ. (как я лет ~20 назад и делал) В тех TI DSP, которые имеют байтовое адресное пространство (C6000 TI DSP), там ROM-загрузчики принимают .ais-образы. Которые и не бинарные (как таковые) и не .hex. А значит у ТС-а явно не такой DSP. Скорее всего - у него что-то из семейства C5000. Хотя может и младшее семейство C2000 - я про них ничего не знаю.
В зависимости от того, что нужно сделать. Набор ключей указан на картинке, описание по ссылке. Я же не знаю, что вам нужно, какие у вас задачи. К примеру у меня файл hex в котором нужное мне место начинается не с начала, а с адреса 0x0C000 я запускаю hex2bin.exe -s 0x0C000 namefile.hex на выходе получаю namefile.bin в нужном формате и без "лишних" байтов в начале.
jcxz, не знаю. Но Вы конкретно уточнили одно семейство, предположили другое, значит, наверное, есть...
Кроме DSP я знаю ещё разве что у некоторых семейств PIC-ов память программ бывает нестандартного размера = 14 бит или другой разрядности. Но CCS с PIC-ами не работает, только с DSP и ARM-ами вроде как. Ну может ещё с MSP430, но в MSP тоже байтовое адресное пространство.
попробуй в кодевижене встроенным программатором перекодировать...
_________________ Просто не учи физику в школе, и вся твоя жизнь будет наполнена чудесами и волшебством Безграмотно вопрошающим про силовую или высоковольтную электронику я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса...
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 6
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
