Событие абсолютно достоверное.
IAR при компиляции программы скомпилировал HEX файл с ошибкой. У меня в знакогенераторе не светилась одна точка в одной букве одного из 10 фонтов. Но это было в двух изделиях с этой прошивкой. То есть это явно не ошибка кристалла или программатора. После перетрансляции хомут исчез.

Прошивал я AVREALом и, честно говоря не глянул на сообщения. Но скорее всего ошибки в строке (КС) не было. А то я бы механически отметил что что-то не так.

Я, конечно всё понимаю, но если возникла ошибка в данном месте, то она могла возникнуть и в любом другом. Хотя до этого таких хомутов не было замечено.

Были ли ещё у кого-нибудь так, что без изменений в программе прошивка генерилась разным образом (с ошибкой) или не верить своим глазам и списать на пятна на солнце?

А какая версия компиллера использовалась?

Все возможно. Был случай когда результат компиляции зависел от положения переменной типа volatile в структуре. В одном месте структуры она иногда не считалась volatile и компилятор "оптимизировал" обращения к ней, при перемещении в другое становилось оной. Замечено в IAR EW430 версий 3.30A и 3.42A. В более ранних не обращал внимание или не встречался с таким проявлением.

IAR Assembler for AVR
4.12A/W32 (4.12.1.5)
C:\Program Files\IAR Systems\Embedded Workbench 4.0 Evaluation\avr\bin\aavr.exe
07.12.2005 14:31:42, 585728 bytes

Translates Atmel assembler to IAR assembler
1.25 (1.2.4.109)
C:\Program Files\IAR Systems\Embedded Workbench 4.0 Evaluation\avr\bin\atmel2iar.exe
14.11.2005 10:00:12, 1716224 bytes

IAR C/C++ Compiler for AVR
4.12A/W32 [Evaluation] (4.12.1.3)
C:\Program Files\IAR Systems\Embedded Workbench 4.0 Evaluation\avr\bin\iccavr.exe
07.12.2005 14:03:14, 9588736 bytes

IAR Build
4.7A (4.7.1.0)
C:\Program Files\IAR Systems\Embedded Workbench 4.0 Evaluation\common\bin\iarbuild.exe
07.11.2006 10:04:40, 16384 bytes

IAR Embedded Workbench IDE
4.7A (4.7.1.0)
C:\Program Files\IAR Systems\Embedded Workbench 4.0 Evaluation\common\bin\IarIdePM.exe
07.11.2006 9:54:06, 741376 bytes

IAR Library Builder
1.03L (1.3.12.0)
C:\Program Files\IAR Systems\Embedded Workbench 4.0 Evaluation\common\bin\xar.exe
06.12.2006 18:59:10, 98304 bytes

IAR XLIB
3.29M/386 (3.29.0.13)
C:\Program Files\IAR Systems\Embedded Workbench 4.0 Evaluation\common\bin\xlib.exe
06.12.2006 19:00:34, 430080 bytes

IAR XLINK
4.60E (4.60.5.0)
C:\Program Files\IAR Systems\Embedded Workbench 4.0 Evaluation\common\bin\xlink.exe
06.12.2006 19:02:32, 1384448 bytes

12.06.2007 вышла уже версия 4.30а для AVR (последняя на сегодняшний день).
С этого момента любые разговоры о глючности предыдуших версий перестают быть актуальными.

Не согласен. Не спешу переходить на свежак пока не возникнет сильной необходимости. Мне нужна не свежая программа, а гарантированно рабочая. Меня глюки в IARе интересуют. Думаю что я не одинок.

Абсолютно не разумно. Сначала "нет необходимости" потом необходимость РЕЗКО появится, что-то в стессовой ситуации будет лататься... после чего очередная ветка о "глюках новой версии компилятора" .

Каждый новый релиз содержит список исправленных и известных багов. Можете ознакомитться. Более новая - более "гарантировано рабочая".

Меня не очень, ибо пожалуй наступить на них, полагаю, можно с более-менее заметной вероятностью только при грязном стиле программирования, когда и программист сам не знает, как мысль выразить а компилятор уж и подавно понять не может. За последние несколько лет наступил только на один глюк (исправленный буквально через месяц в следующем релизе). Причем делалась вставка в чужой код и было желание максимально сохранить стиль исходника - за это и поплатился

В поисках глюков в чужом глазу ? Пожалуй .

Приношу свои извинения. Завтра доведу исследования до конца, но первые контуры вроде вырисовываются.

Проблема совсем не в IAR. Но и не в "грязном стиле программирования", как поспешил заявить прославленный zltigo. Не буду спорить с вами. Возможно я не так искушён в программировании как вы, да и у себя самого имеются к себе претензии. Плюс не всегда удаётся реализовать всё что задумал. По разным причинам. Например извечная -- нехватка времени. Я стараюсь совершенствоваться. К тому же порой спросить бывает не у кого. И всё таки мне не нравится попытка навешивать ярлыки совершенно на пустом месте. Не зная человека, не видя его программ. И вообще попытка осудить всех, кто мало мальски отличается от вас.

Ладно не хочется об этом.

Возможная причина - поставка кристаллов atmega2560V вместо atmega640. У меня питание 3.3V и частота потолочная. Ошибка происходит при записи и то не всегда. Попробую поэкспериментировать с частотой записи. Хотя похоже надо просто заменить кристаллы. На мысль об ошибке компилятора навела идентичная ошибка в двух из 6 изделий. Как раз в этих двух стояли новые кристаллы. После перезаписи - всё нормально. Ну я и погрешил на компилятор. Теперь в одном из перечисленных изделий хомут более не наблюдается, а во втором как бог пошлёт при перезаписи. Ещё один момент, - пишу я 4.5V. Тоже можно поэкспериментировать. Самый прикол что программа работает, а вот знакогенератор искажает символы. Пропадают точки. Но не во всех символах и не во всех таблицах фонтов.

Для каждого напряжения своя потолочная частота.

Понятно. Не вчера же я родился. Это я так завуалированно, чтобы не пинали сильно, сказал что частота превышает допустимую. Если быть точным частота 14.7456, питание 3.3V, температура комнатная (10-40 ориентировочно). Обычная 640 или 2560 работает круглосуточно без проблем.

Извините! Ничего личного абсолютно не подразумевалось. И ответ был совсем не на Ваше сообщение.
Все сказаннае базируется ключительно на наблюдением за творчеством лично знакомых мне людей и своим . У меня компиляторы, заразы, тоже глючили ,
но со временем перестали....
Выборка за многие годы накопилась немалая .

Чтобы не плодить новых тем, к тому же не по теме.

Я использую IAR C сейчас. Мне он нравится. Раньше всё писал на ASM. Вижу что назад уже возвращаться не хочется. Была попытка некоторые п/п переписать на ASM и то неудачная. После написания этой процедуры на ASM, я реализовал её аналогичным образом на Си и оказался не в выигрыше а в проигрыше. Короче вижу, что возврата нет. Но теперь возникла новая проблема.

Раньше я на PC использовал DELFI. В последнем проекте, к примеру, у меня имеется эмулятор изделия на PC. И получается совершенно очевидный бред. Прога на Си, а эмулятор на pascal. Разница то не большая, но смысл в том что я бы как раз целые куски мог заимствовать! А так нет, приходится наново переписывать. В принципе и это не беда, но желательно чтобы максимально близко работало, а то при переносе, то там, то там неточность влеплю и ищу потом клопов. В ближайших планах bootloader и протокол передачи общий. И опять на разных языках.... Короче требуется волевое решение принимать. Я уже и книжку подкупил. И вот отсюда вопрос.

Что именно пользовать на стороне PC?

С одной стороны на C++ Builder от Борланда переходить будет явно проще. Там даже компоненты будут те же и среда та же. То есть переучивания будет минимум. С другой стороны начинаю я практически с чистого листа, так может сразу на Visual C от MS? По тиху привыкну. Несколько пугает навороченность. Установил - глянул, даже привычной палитры инструментов не нашёл. Короче я на распутье.

Что посоветуете, специалисты?

я не специалист вовсе, но немного поработал в VS. Палитру инструментов можете там не искать ее нет, ибо философия VS отлична от BC. Мелкомягкие пропагандируют другой подход к разработке интерфейсов. Если нужны именно интерфейсные части и компоненты то BC, если в основном пишете консольные приложения то мне больше нравиться VS.

Удачи!

Борланда, пожалуй не надо. Совсем не надо. Жутковатый эклектичный продукт в результате вырос. Если речь идет о Win приложениях с навороченными GUI, то при всем богатстве выбора - VS . Если основной упор не GUI, то лично я практически всегда традиционно использую Open Watcom (заодно и некая многоплатфоменость присутствует - прямо некоторве вещи им компилятся под Linux и под встренные x86).
Есстественная альтернатива всему и вся - GCC , но его пользую редко, разве только для компиляции больших, запутанных и заточенных под него чужих C++ кусков.

Для версии с букавкой V судя по даташиту Fmax=8mhz. Может я чего не так понял

Да правильно вы всё поняли. И обратите внимание ещё на такой момент
при U=1.8-2.7 Fmax=2MHz !!!!!!!!
в то время как для atmega640V при U=1.8-2.7 Fmax=4MHz, что на мой взгляд говорит о том что 2560 более медленно ворочается под низким напряжением. Скорее всего проблема именно во флэш. Она то и глючит.