Внимание! баг в 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,

Reply to
Oleksandr Redchuk
Loading thread data ...

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.