Отправлено vmp 19 ноября 2004 г. 18:44 В ответ на: генерит НЕХ. В чем аккуратность нужна? отправлено ATmega128 ? 19 ноября 2004 г. 18:24

От:Alexandr A. Redchuck (XXXX@XXXX.XXXX.XX)
Тема:"Глюки" при зашивке (в дополнение к AVR ASM --> IAR ASM :-) 
Это единственная статья в данном разделе  
View: Original Format 
Группы новостей:fido7.ru.embedded
Дата:2002-07-15 03:11:57 PST 
 
Hi, All!
Мне уже приходил несколько подобных писем, но я каждый раз не сохранял
ответ и каждый следующий раз отвечал заново.
Вопрос уже вполне тянет на FAQ, причем сразу в двух номинациях :-)
  Q. При зашивке в mega103 код на границе страниц не работает...
и
  Q. Почему надо выкинуть подальше AVR ASM и перейти на IAR ASM?
поэтому я его дублирую сюда и "принимаю за основу".
Q.>>> Есть железка в которой стоит ATmega103L.
Q.>>> Если программа переходит границу в 64к то код находящийся на границе
Q.>>> страниц неработает :(
Q.>>> Сначала я пользовался программатором PonyProg(первое что нашлось)
Q.>>> потом заметил, что этот PonyProg на границе страниц вставляет 0xFF даже
Q.>>> если в hex-е записаны одни нули.
Q.>>> Пришлось озадачиться поиском другого программатора,
Q.>>> ваш оказался следующим :)
Q.>>> Ситуация повторяется, если код или данные попадают на стык страниц,
Q.>>> то они неверны :(
Q.>>> Может это глюк ATmega ?
Q.>>> А может программатора?
Q.>>> Я уже не знаю что делать :(
AR>>  А чем компилируется программа, т.е. откуда берется HEX файл?
Q.> Компилю из AVRStudio 4.03 пробовал и более старыми версиями результат
Q.> один.
  Поскольку нет уточнений о том, что к оболочке AVRStudio прикручен
другой компилятор, то компилируется avrasm by Atmel. "я так и знал" :-)
AR>> В данном случае это не менее важный момент.
 [^Y]
AR>> Я специально генерировал IAR 1.40E файл большого размера (забитый
AR>> инициализированными массивами), пишется-читается правильно.
Q.> В смысле програмируется и считывается? С этим проблем небыло,
Q.> проблема в том что зашитая программа не работает.
  Не просто считыватеся (верифицируется), а считанный из кристалла
файл независимо сравниватеся с исходным HEX-файлом. Ведь если возникают
какие-то проблемы со чтением HEX-файла в программатор, то они
возникают и при чтении перед записью, и при чтении перед сравнением.
В данном случае я делал бы так. Исходный файл преобразовать в бинарный,
это команда
   hex2bin /L131072 /P255 ppu2.hex ppu2.bin
Этот же исходный файл записать в кристалл, затем прочесть из него
в файл ppu2rd.hex и преобразовать
   hex2bin /L131072 /P255 ppu2rd.hex ppu2rd.bin
Сразу становится ясно, в чем дело. Если ppu2.bin и ppu2rd.bin
совпадают, то ошибка с большой вероятностью не в программаторе,
так как адреса в нем обрабатывает один и тот же код.

Q.> Разбираться сейчас к сожалению времени нет :(
AR>> wbr,
AR>> p.s. я и так отклонился в разборе записей segment address record
именно ради avrasm, так как давно заметил, что он не делает
"сворачивание" адресов при segment address режиме.
AR>> в надежде, что ни один софт "в здравом уме" не будет
AR>> реально сворачивать адреса "по интелу" - просто сгенерирует две
AR>> записи, одну перед границей 64K, одну на нулевом адресе.
AR>> Но недавно мне высылали для разбора полетов HEX-файл, в котором
AR>> были настолько неправильно порождены записи на границе 64K,
AR>> что их только вручную текстовым редактором можно было исправить.
Q.> Я высылаю вам два файла ppu.hex и ppu2.hex они отличаются тем что
Q.> в исходной программе для ppu.hex вставлено .cseg 0x8000.
Q.> ppu.hex работает, а ppu2.hex нет. Неработает именно та часть что
Q.> находиться на стыке страниц.
Q.> Самое странное , что в симуляторе все работает.
 Было бы странно, если бы Atmel сам себя не понимал :-)
Atmel договорился сам с собой, что HEX-файл для >64KB должен
выглядеть так-то и так-то. Но почему-то для этих файлов оставил
название Intel hex :-)
Рассмотрим присланные файлы.
==================
ppu.hex:
line1:    :020000020000FC
line2:    :020000002BC013
line3:    :040028000C944109EA
line4092: :10FF9400224006C80019200364800C900138FBFF3E
line4093: :02FFA400FF005C
line4094: :020000021000EC
line4095: :1000000003E00C94B6070093D600B0E0A7ED0E9481
line4096: :10001000F60722C028E03AE0B1E0A8E30D911C9178
line7895: :10ED8000C00000001ABB0400001B070000001C00AC
line7896: :04ED90000000001F60
line7897: :00000001FF
Тут все нормально. Строка 1 устанавливает сегментный адрес в 0. В
принципе,
это не обязательно, так как при старте разбора все расширения адреса
должны быть обнулены.
Строка 4093 делает последнее занесение данных в нижние 64KB, остается
некоторое свободное пространство, так как в коде была директива
.cseg 0x8000 (avrasm, словная адресация).
Строка 4094 задает размещение данных дальнейших записей начиная с
сегментного
адреса 1000h, т.е. с полного адреса 10000h (байтовая адресация в hex-файле).
===============
ppu2.hex
line1:    :020000020000FC
line2:    :020000002BC013
line3:    :040028000C944109EA
line4096: :10FFD4006FE150E842E9699359934993D0E0C7ED42
line4097: :10FFE4006993599343604993088100600F710883B2
line4098: :020000021000EC
line4099: :10FFF400239600E108830091D600B0E0A7ED03E06A
line4100: :100004000C94BC0710E10E940504C59A01E00E940B
line7895: :06ED34001C000000001F9E
line7896: :00000001FF
Ну а тут... "Нет слов, одни выражения" (C) народ.
Строка 4097 заносит 16 байт данных в адреса 0FFE4h-0FFF3h.
Адреса 0FFF4h-0FFFFh пока не заполнены.
Строка 4098 устанавливает базовый адрес для последующих записей на
10000h.
Строка 4099 после этого заносит данные в адреса 1FFF4h-20003h
Строка 4100 заносит данные в адреса 10004h-100F4h
Итого область 0FFF4h-0FFFFh так и осталась пустой, зато
в область 1FFF4h-1FFFFh пространства кода (flash) записаны никому
не нужные данные. Далее, поскольку с версии 1.22rev4 (Thu 09-Aug-2001)
"Добавлена возможность задавать содержимое кода и данных в одном
файле, информация для EEPROM должна находится в HEX-файле начиная с
адреса, равного размеру кода для специфицированного в командной строке
кристалла.", информация из адресов 20000h-20003h смещается в адреса
0-3 и помещается в список для записи EEPROM данных!
Можете сделать преобразование с длиной файла 20004h=131076dec
hex2bin /L131076 /P255 ppu2.hex ppu2.bin
и убедиться, что не только avreal нашел в ppu2.hex байты
для адресов 1FFF4h-20003h и ничего не нашел для адресов 0FFF4h-0FFFFh.

Остается только посоветовать перейти на IAR ASM, он бесплатен
и тоже есть на сайте atmel.
Q.> P. S. Я пробовал создавать hex с одними нулями прогой bin2hex от 51-го
Q.> ассемблера
Q.> BIN2HEX Version 1.06
Q.> Copyright (c) 1993-1995 BITWARE.
Q.> All rights reserved.
Q.> В результате в текстовом редакторе этот hex выглядит правильным,
 Не совсем...
Q.> но в PonyProg после 64к все 0xFF, а ваш программатор вообше ругается
Q.> "HEX file records overlapped in addresses 0x0-0xFFF"
 Смотрим этот q.hex.
В записях данных я для краткости убрал все кроме длины и стартового
адреса, оставил только важные для понимания строки
line1:    :200000
line2:    :200020
line2047: :20FFC0
line2048: :20FFE0
line2049: :200000
line2050: :200020
line4095: :20FFC0
line4096: :14FFE0
line4097: :00000001FF
В пределах первых 64KB все нормально. Дальше при переходе ко вторым 64K,
после строки 2048, должна была быть запись расширения адреса.
Либо тип '02' Extended Segment Address Record
:020000021000EC Либо тип '04' Extended Linear Address Record
:020000040001F9
Из-за отсутствия этой записи строка 2049 помещается туда, куда указывает
ее адресная часть, а именно в смещение 0h (хотя хотелось, чтобы было
10000h).
Но, поскольку в это место уже было что-то записано - строкой 1, avreal
выдает сообщение о перекрытии адресов. PonyProg либо просто не анализирует
перекрытия, либо смотрит, что записываемые поверх байты совпадают
(ведь весь файл нулевой) и молчит. А остаток свыше 64KB оставляет
неинициализированным, 0FFh по умолчанию.
В данном случае программе bin2hex необходимо было сказать,
что следует сгенерировать расширенный формат HEX-файла. Для программы
BIN2HEX Version 1.06
Copyright (c) 1993-1995 BITWARE.
это ключи /2 и /4 для  Extended Segment Address Record
и Extended Linear Address Record соответственно.
wbr,
--
/* Alexandr Redchuck, Kyiv, Ukraine */
/* real на real тчк kiev тчк ua     */

--------------------------------------------------------------------------------
 

• http://www.google.ru/groups?q=intel+hex+atmel+avreal+group:fido7.ru.embedded&hl=ru&lr=&ie=UTF-8&inlang=ru&selm=2.07b5.QE0Z.GZABVI%40real.kiev.ua&rnum=1