MPLab - несовместимость версий? Опции

[FPGA]

Доброго времени суток!
Обращаюсь ко всем, имеющим опыт работы с версиями MPLab IDE разных лет. Проблема такая. Имеется прошивка для PIC16F877, разработанная в 2002 году. Код был написан на C с небольшими вставками на ассемблере, среда разработки MPLab v5.20 (или что-то около) в связке с компилятором HI-TECC PICC (версию назвать сейчас трудно, но что-то около v8.86). Все прекрасно прошивалось в течение многих лет, устанавливались свежие версии MPLab без каких-либо проблем, и все продолжало нормально прошиваться. Потом прибор прекратили выпускать и долгое время не трогали, при этом продолжая освежать на рабочем компе MPLab по мере необходимости. Недавно нам заказали новую партию приборов, и тут оказалось, что прошитые с использованием оригинального файла контроллеры работать отказываются. Начали разбираться. Проверили контрольную сумму hex-файла в архиве и на мастер-диске с помощью MPLab v8.12, в данное время установленной на производственном компе. Оба результата были одинаковыми, но не совпали с ожидаемой суммой. После этого прочитали прошивку исправного прибора с помощью той же v8.12, значение контрольной суммы совпало с ожидаемым. Казалось бы, это проблема архивных файлов, но дело в том, что при прошивании процессора специальная утилита подсчитывает CRC прошивки и добавляет ее значение в записываемый дамп, чтобы процессор мог проверить прошивку во время самотестирования. Так вот CRC всех трех файлов оказалась одинаковой и в точности той, что ожидалась. После этого нашли очень старый комп с древней версией MPLab и прошили несколько контроллеров файлом из архива. Все прошло идеально. Но при использовании v8.12 заработал только контроллер, прошитый файлом, слитым с рабочего прибора. Также оказалось, что размер hex-файла, слитого с рабочего прибора версией 8.12, отличается от размера архивных копий. В итоге был сделан вывод, что файл, созданный ранней версией MPLab, трактуется как-то иначе более свежей версией.

Вопрос - встречался ли кто-нибудь с подобной проблемой, что старые hex-файлы при заливке более свежей версией MPLab перестают работать на железе, с которым раньше работали? Возможно, Microchip изменил метод подсчета контрольной суммы или что-то еще, в результате чего более свежие версии MPLab иначе трактуют старые hex-файлы. Если что-то подобное имело место, может, у кого есть официальные микрочиповские документы или апноты на этот счет, подтверждающие данное предположение. Перекомпилировать проект под более свежей версией MPLab не вариант, т.к. потребуется дорогостоящая пересертификация, чего хотелось бы избежать. Старый же комп с древней версией MPLab более не доступен, так что использовать его тоже не вариант. Похоже, что надо откатить назад версию MPLab, но хотелось бы не откатываться дальше, чем нужно, т.к. на компе программируют и другие, более свежие, MPLab проекты. Не хотелось бы тупо пробовать разные версии, пока не заработает. В общем, подскажите, друзья, кто что знает.

[FPGA]

Друзья, большое человеческое вам всем спасибо! И особая благодарность ViKo за толчок в сторону дизассемблирования. Тут такой расклад нарисовался. CRC hex-а прописывается в него же для проверки при самотестировании, т.е. проц считает CRC своей флеш-памяти без этой ячейки, а потом сверяет с ней полученный результат. Если все совпало, работаем, если нет, сваливаемся в повтор, и так до бесконечности. Так вот. Дизассемблировал с помощью v8.12 два файла - архивный и слитый с живого прибора этой же версией. На слитом файле среда видит содержимое этой ячейки правильно и в самом hex-е, и в листинге после дизассемблирования. А вот в архивном файле, созданном в более старой версии - только в hex-е, а в листинге неведомо откуда появляется 0000, т.е. NOP. Вот тут собака, судя по всему, и порылась, т.е. проц просто сваливается в ошибку. Дальше пусть уж начальство решает, что делать. Хотя для себя очень хотелось бы понять, почему такая хрень происходит... Так что похоже, что наиболее близкими оказались предположения Ruslan1 по поводу hex-файла.

Я думаю, причина одна из нижеперечисленных:

1. hex-файл неполный, то есть не содержит некоторую значимую информацию (какие-то биты конфигурации, например, или EEPROM). А дефолты поменялись.
...
...
3. Hex-формат файла поменялся или дополнился и новый программатор корректно (или наоборот некорректно) начал читать данные из старого файла, приготовленного до этих нововведений)

И еще, не знаю важно это или нет, но эта ячейка - последняя из заполненных, а по предыдущему адресу записана команда RETURN, т.е. возврат в начало программы. Черт его знает, может среда игнорирует все, что после RETURN-а находится?! Хотя границы заполненной памяти вроде бы указывает корректно.