Внимание! баг в IAR-овском postlink?

Hi, All!

Может, $(SUBJ). Может, что-то не так сделано до него (там замешан ещё
какой-то 1.raw, а я в иаровских путях не разбираюсь).
Короче, вот итог очередной моей переписки.


28-Jul-04 10:03 avreal user wrote:

 s>>> при использовании Вашего avreal возникла интерезная загвоздка.
 s>>> размер проекта превысил 64К, при этом выходной файл, создаваемый
 s>>> IAR'овским postlink (я вынужден им пользоваться, т.к. у меня в
 s>>> проекте используется инициализированный EEPROM) перестал шиться с
 s>>> сообщением "memory overlapping", причем в области старших адресов(!).
 s>>> после проведенного эксперимента выяснилось, что extended-hex,
 s>>> создаваемый линкером напрямую, шьется без проблем. оказалось, что
 s>>> они по-разному обозначают расширенные сегменты памяти (>64K, а
 s>>> именно xlink - директивами 02, а postlink - 04. очевидно, avreal
 s>>> как-то не так понимает оную директиву? процессор - mega128, IAR
 s>>> 3.10C, тестовый проект могу выслать при необходимости

OR>>  Вышлите hex-файлы обеих вариантов, я посмотрю как они сделаны.

 s>  все три в прицепленном файле. исходник такой
 s> #include <iom128.h>

 s> __flash char foo1[0xff00] = {0, };
 s> __farflash char foo2[0xff00] = {0, };
 s> __eeprom char foo3 = 0;

 s> void main()
 s> {
 s>         unsigned int i;
 s>         for (i = 0; i < 0xff00; ++i)
 s>         {
 s>                 foo3 = foo1[i] + foo2[i] + foo3;
 s>         }
 s> }

[...]

 s>   win32. вот батник, который все делает

s> @echo off
s> postlink.exe -intel-extended -code -data -idata -bit -const -untyped
s> 1.raw 1.hex
s> postlink.exe -intel-extended  -xdata 1.raw 1e.hex
s> avreal32 -p1 +mega128 -! -ewp 1.hex 1e.hex
s> avreal32 -p1 +mega128 -! -ewp 1.a90 1e.hex
s> exit

OR>> p.s.2 есть "независимый" способ проверки, надо каким-то
OR>> конвертором hex-bin конвертнуть оба файла, из-под xlink и из-под
OR>> postlink и сравнить бинарники.

s>  я специально нулевые файлы скомпилял, по совету Harry Zhurov, для
s>  проверки. с виду файлы в обоих случаях вполне корректные. кстати,
s>  напоминаю, что до момента пересечения границы 64К все работало
При внимательном рассмотрении файлов оказалось, что постлинковский
файл не такой белый и пушистый, как прикидывается.
  А совет Журова правильный, так как в "боевом" файле будет каша из
секций и вручную сравнивать тяжело.
  Мой же совет про конвертацию в bin и сравнивание бинарников тоже надо
было использовать :-)

[...]

28-Jul-04 12:14 avreal user wrote:


 s>   все, я разобрался (надо было раньше подумать). прочел avreal'ом
 s>   прошивку в hex (а он ведь в 4-м формате сохраняет!), прочитанная
Это методологически неправильно. Если ищется бага в avreal, желательно
сделать проверку хотя бы в одном из направлений другой программой.
Мало ли, может у меня там две ошибки :-)

 s>   прошивка шьется нормально. сравнил - отличаются файлы только
 s>   наличием у postlinkовского в самом начале записи
Не только.

 s>   :020000040000FA

 s>   отсюда и мораль басни - баг в авриле в разборе записи 04 с нулевым
 s>  адресом

Мораль другая. Или как-то не правильно сформирован 1.raw, или
неправильно вызван постлинк, или "Платное - не значет без
багов" :-)

Итак имеем присланные:
1.a90 = файл из-под xlinka
1.hex = из-под постлинка, сделан из какого-то 1.raw

hex2bin 1.a90 1-a90.bin
hex2bin 1.hex 1-hex.bin
fc/b 1-a90.bin 1-hex.bin


Сравнение файлов 1-A90.BIN и 1-HEX.BIN
00000004: 18 00
00000005: 95 00
[... куча адресов подряд поскипаны]
0000008A: 18 00
0000008B: 95 00
00010004: E0 18
00010005: 9A 95
[...]
0001008A: 00 18
0001008B: 00 95

Мда... В принципе, после этого можно послать за дальнейшими ответами к
IAR-овцам :-)

Но ведь интересно же, где они умудрились наколотся?
 Продолжение в следующем письме...

wbr,