Доброго времени суток!
Обращаюсь ко всем, имеющим опыт работы с версиями 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 проекты. Не хотелось бы тупо пробовать разные версии, пока не заработает. В общем, подскажите, друзья, кто что знает.

Добрый день!
Самому мне не приходилось ни разу заниматься сверкой контрольных сумм, независимо от версий всегда заливалось на ура. Но при этом, я регулярно практикую заливку готового hex на партию устройств не с помощью MPLab, а с помощью спец.программ идущих с программатором. Например, у меня PicKit2 и PicKit3, для них есть соответствующие программы PicKit2.exe и PicKit3.exe. Они весят меньше, ИМХО с ними проще и быстрее.
Что бы я делал в вашей ситуации:
1. Слил бы самую последнюю версию MPLAB IDE (вкладка Downloads Archive) . На текущий момент 8.92. Версии 8.12 на офф.сайте я не увидел. Если это был баг среды, то скорее всего они его исправили.
2. Вариант попробовать MPLAB X. Он очень прожорливый и неповоротный для "медленных" компов, но как вариант тоже сгодится.
3. С MPLabX в комплекте идет программа MPLAB IPE - универсальная программа заливки hex для всех (до конца неуверен, что для всех, не проверял) программаторов и чипов.

а что, Ваш программатор только из под IDE работает?

Во-первых, спасибо всем откликнувшимся.

Честно говоря, у меня есть серьезные сомнения, что это баг. Почему-то мне кажется, что это совершенно осознанная смена "чего-то там" Microchip-ом. Почему так думаю? Да потому, что они в прошлом меняли форматы, в частности, в очень старых версиях, включая и 5.20, файл проекта имел расширение .pjt, а в более свежих - уже .mcp, причем более свежие версии старый формат не распознают. И кстати, если память не изменяет, то где-то начиная с v8.40-какой-то они снова что-то меняли, так что велик шанс получить новые проблемы, установив последнюю версию 8.92. Что же касается MPLABX, то мы предпочитаем старый и надежный ICD2 более новому и кривому ICD3, а MPLABX поддерживает только последний, если не ошибаюсь. Есть еще где-то в закромах PM3, но его сначала еще найти надо. В общем, похоже, что таки придется методом тыка, хоть и не хотелось. Если больше ничего не посоветуют, то будем пробовать ваш подход, ну и откатываться назад тоже попробуем. Еще раз спасибо.


У нас основной программатор - это ICD2. Да, он из-под IDE работает. Есть еще где-то PM3, он вроде бы поновее, и он умеет кроме загрузки файла средой также считывать прошивку с образцового чипа или с карты памяти, НО!!! проблема снова в том, что любой из этих методов требует либо использования среды, а она явно калечит файл, либо создания образцового чипа обходными путями, а это с точки зрения сертификационных служб является основанием для пересертификации. Можно, конечно, слить исходный hex на карту памяти средствами винды и воткнуть эту карточку в PM3, но не факт, что для сертификаторов это прокатит, т.к. помимо всего прочего, файл заливается с карточки, а не прямо из архива. Вот и получается, что нужно обязательно найти способ работать с оригинальным hex-ом. Но в любом случае спасибо за Ваше мнение.

Никакая версия MPLAB не может испортить hex. В конце концов, его же элементарно можно восстановить-дизассемблировать усилием мозга.
А вот сами микроконтроллеры могут слегка измениться - технологии меняются = быстродействие, дополнительные периферийные устройства, диапазоны частот и напряжений. Добавляют буковку A в конец, и программа уже не работает.

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


Да все буковки проверены уже 100500 раз, тем более, что в среде можно выбрать вариант и с буковкой, и без. На сегодня факт непреложен - один и тот же файл, залитый в одну и ту же микросхему, работает при заливке одной версией MPLAB, старой, и не работает при заливке другой, более свежей. Вы можете возразить, что кривой комп, так вот отвечаю - с более свежей версией пробовали на нескольких компах, меняли ICD2, USB кабель, кабель ICSP интерфейса - результат один и тот же. Что ваш мозг на это скажет? Хотя дизассемблировать ради интереса все же попробую, когда со временем посвободнее будет. Дизассемблер посоветуете?

Выскажу частное предположение. Может быть затык связан с битами конфигурации? Например, в hex-файл они не включены, и при заливке они тягаются из значений по умолчанию, а в разных версиях среды они разные.
Чтение с залитых в двух случаях чипов hex и сравнение должно дать ответ по каким адресам различия начались, и собственно почему контрольная сумма отличается.

вероятно в более "свежих" версиях IDE внесены изменения в протоколе работы с ICD3, которые и приводят к такому эффекту, проверить - зашить МК хексом не используя IDE и/или ICD3

А hex файл, прочитанный в MPLab, не представляется в виде команд? У меня не стоит, не помню.
Согласен с Redguy - не задано сохранение конфигурации в hex. А как насчет EEPROM?

Извините, но это полтергейст какой-то. Не может программатор изменять hex-файл. Если просто залить в MPLAB файл с диска и зашить- то никак версия МПЛАБа не должна влиять на содержимое тех адресов флеша, которые явно описаны в данном файле. Я думаю, причина одна из нижеперечисленных:

1. hex-файл неполный, то есть не содержит некоторую значимую информацию (какие-то биты конфигурации, например, или EEPROM). А дефолты поменялись.
2. Программа использует области, которые не описаны явно в hex-файле, не занятые кодом и данными (например, в расчете CRC). А что делает программатор с этими областями- не указано и выполняется по дефолту, может стереть в FF а может и не трогать. А дефолты поменялись.
3. Hex-формат файла поменялся или дополнился и новый программатор корректно (или наоборот некорректно) начал читать данные из старого файла, приготовленного до этих нововведений)
4. что-то еще. что было по дефолту и не задано явно
5. Некорректная работа стороннего софта на компьютере (ну мало ли на каком пентиуме без плавающей точки это было написано).
6. человеческий фактор. ошибки во время эксперимента переповторить другими руками в другой день недели.
7. полтергейст: плавающие биты и нанохаккеры

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



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