Проблема!!!!
При программировании по внутрисхемному интерфейсу сыходят из строя конттроллеры (не функционируют, мертвые). Схема рабочая(перепайка процессора и работаем).
Питание при программировании от программатора.

Питание подается , считываются программатором, перепрограммируются, верификация ОК!, но не работают. И таких доходит до 10%, от общего кол-ва.

Контроллер: PIC12F675
Конфигурация: __CONFIG(UNPROTECT & BOREN & MCLRDIS & PWRTEN & WDTEN & INTIO); (HT PICC)
Программатор: ChipProg+ , ПО версия V. 3.95.00 или V. 4.00.12 Beta

Не знаю как PIC16F675, но PIC18F1320-I/P имеют определенный процент (~0,8%) "непрограммируемых" микросхем. Иногда помогает исключение защиты памяти.

Скорее всего слетает байт калибровки (точнее, программатор неправильно его считал, а потом записал не думая, что получилось). Что живет в убитых кристаллах по адресу 0x3fe? Должно быть что-то вида 0x34xx (retlw xx), xx - и есть заводская калибровка.

Может быть по адресу 0x3fff, по моему в этом адресе ложат кончтанту, + программатор ограничивает доступ к последнему элементу от 0 до 0x3fe.

Но согласен проверка не помешает

Есть вероятность что портятся байты конфигурации bandgap (неправильно читаются или еще как)

Буду проверять , программатор не разрешает эти биты произвольно править.

Вам на microchip.ru уже все сказали - если вы нарушаете спецификацию программирования - никто вам не поможет. Используйте нормальный программатор и выкусите конденстатор 100 мкф по питанию. trt вам все подробно объяснил.

Проверьте в битах конфигурации правильно ли Вы выбрали режим ГЕНЕРАТОРА.
Вероятнее всего причина в этом. А программатор ChipProg+ - замечательный, пользуюсь им уже
более 4 лет и никогда не было вопросов. Кстати, уже на сайте Phyton.ru выложен 4.32, но это никак
не соотносится с Вашей проблемой !

Причина может быть и в низковольтовом программировании. В моей практике 3-5 раз и
контроллер перестает записываться.С 14 вольтами они не спорят.
Если верификация Ok, то вероятно контроллеры исправны.Прочитайте в них память и конфигурационное слово.

Я хочу уточнить. Нужен ответ: они будут программироваться, НО возможно работать НЕ будут.

Если я нарушаю спецификацию, программатор ( если он хороший) должен сообщить мне об этом, а на деле программаторникакого несоответствия не обнаруживает.

Я обязательно изменю конденсатор и проведу пробное программирование партии, но я хочу выяснить что именно выходит из строя(затирается в памяти), нужно узнать причину

Разрядность инструкции контроллера PIC12F675 составляет 14 бит. При просмотре дампа памяти программы удобно включать режим просмотра по 2-хбайтовым словам. Инструкция возврата калибровочного значения располагается по адресу 0x3fe, и там должно быть именно 0x34xx. Подробности в даташите.

И это правильно (это я про то, что "не разрешает"). Подробности в даташите.

У меня под рукой и ChipProg2, и ProMate2, и PICStart, так что есть с чем сравнивать.
Могу сказать, что ChipProg при внутрисхемном программировании спокойно справляется с емкостью 100 мкФ по питанию, но очень желательно при этом использовать соответствующий адаптер - буферы по PGD, PGC в программаторе слабоваты.
На ProMate было от души матов сложено за бесподобную конструкцию установки адаптеров - вместо разъемов две полоски токопроводящей резины - типа работаем с ЖК-индикатором. Дорогая малополезная игрушка.
PICStart - development programmer.
Еще одна возможная причина отвалов - плохой/мерцающий/зависящий от человеческого фактора контакт в используемом разъеме ICSP.

соответствующий адаптер истользую, сделанный самостоятельно по схеме предложенной производителем Chip Prog. Сделан качественно.

Конечный адрес в микросхеме установлен 0х3fe,

С асемблером общаюсь на ВЫ, программны на нем не писал (больше уважаю С ), но листинг в узких местах алгоритмов смотрю и оптимизирую(по возможности).

В одной из неработающих МС действительно удалена команда возврата и константа, каким образом - непонятно (может жертва экспериментов), с этим ясно.

вот код который загружает константу (стандартная директива ht-picc):

/*----- настройка генератора ----- */
365:
366: OSCCAL = _READ_OSCCAL_DATA();
BCF 0x3, 0x5
CALL 0x3ff
BSF 0x3, 0x5
MOVWF 0x10

практически, на мой взгляд, эдентично даташиту

Если не сложно обьясните почему CALL 0x3ff а не CALL 0x3fe

Контакт слотовый , может быть и мерцающим (но мне кажется программатор при верификации должен сообщить о несовпадении)

Извините, утро вечера гораздо приятнее. 0x34xx в 675 живет по адресу 0x3ff. Был неправ.
Каким образом программаторы умудряются запороть калибровку, мне не понятно. Приключалось на всех помянутых мной программаторах. Тот же ProMate при верификации спокойно заявляет "Calibration bits invalid", хотя начало программирования предполагает, что предварительно было считано что-то вроде 0x34xx (иначе он сразу орет про калибровку и ничего не делает).
Самое гадство - ни ProMate, ни ChipProg не позволяют записать калибровку с потолка (например, 0x3480 как середину диапазона). Я восстанавливал калибровку на PICStart'e под MPLab 5.7, которые еще не были такими умными. Сейчас забил, и, т.к. число отвалившихся микросхем плавно приближается к 200 (на ~50000 запрограммированных), студент в фоновом режиме пишет прогу для восстановления калибровки.

Давно пользуюсь для программирования программой WinPic и простым программатором на сом порте. Из 10000 ни одного прокола. Там кстати можно менять значение калибровки.

За ChipProg замечено - есть проблемы с ICSP, особенно с 18хх - с родной "шайбой" (icd2) проблем в тех же условиях нет

PICkit2 умеет восстанавливать утерянную калибровку методом прошивки маленькой программы которая дергает ногой, PICkit2 измеряет частоту и восстанавливает калибровку. Так что если студент умный - посмотрит исходники PICkit2.

У меня похожая проблема, только пик 12f629 и он нехочет программироваться. Читается, вся память 3fff, конфигурация 3fff, ID - FFFF. Поидее распиновка ног таже что и 12с508(509), программатор JDM, и ICProg и WinPIC ставят один и тот же диагноз. Насколько я понимаю спецификация программирования закладывается в программе, но оба программатора поддерживают 12f629. Заметил однако одну особенность, когда вставляю 16f84a или 16f876a (с другими пока неработал, но с этими никаких таких проблем небыло) WinPIC распознает ее правильно, а когда вставляю 12-й - пишет "устройство нераспознано". Как я понимаю это проблема конкретной микросхемы, может кто сталкивался с подобным и лечится ли это или попробовать прошить другой экземпляр??

Говрят что 12е пики если один раз запрограмить с внутренним осйиллятором на некоторых программаторах потом нешьются уже.... так что похоже это именно та ситуация.

Проблема решилась странным необъяснимым образом - потыкав паяльником и поменяв стабилитрон в схеме JDM для понипрга на светодиод 12й пик начал шиться (правда только испрогом, винпик попрежнему неможет) и читаться даже с внутренним осциллятором.... Чудеса да и только

Студент умный, и именно поэтому вряд ли станет разбираться в сотне с лишним кБ сорцов и скриптов PICkit'а, чтобы написать пару несложных прог в в 200-300 слов. А, учитывая, что хост слепили на AVR, и хочется все делать внутрисхемно (а, как продолжение темы, слепить на этой базе пяток-десяток автономных программаторов, чтобы народ на сборке не сачковал), тем более.

Поведение, описанное Вами в предыдущем посте, возможно при использовании в качестве программатора ICD2, если в конфиге PIC'а задан внутренний RC-генератор и внутренний же сброс (нога MCLR используется как вход). Этот случай и его причина описаны в доках к ICD2.
В схеме JDM для понипрога не нашел светодиода (схема, если Вы о ней, впечатлила - при ее использовании невозможно соблюсти спецификацию программирования PIC'ов с указанным выше конфигом по той же самой причине).

Вобщето схема не совсем эта, а вот эта http://www.lancos.com/e2p/si-prog-v2_2.pdf и светодиода в ней по умолчанию нет, я его поставил вместо стабилитрона который идет на MCLR, но это больше для наглядности в процессе программирования - врядли светодиод несет еще какуюто функциональную нагрузку. Хотя по большому счету все эти схемы похожи.

Позвольте не согласиться. Схемы в упомянутой Вами pdf-ке по сравнению с адаптером JDM можно считать творением мастера хотя бы из-за возможности подачи внешнего питания.
Но и там в схеме адаптера для PIC'ов есть маленькая неточность, с которой, по-видимому, связаны Ваши мученья: напряжение программирования на PIC12xxx идет не со стабилитрона (как на PIC16Fxxx), а прямо с ключа Q5. Исправьте, и будет Вам щастье.

Собственно говоря 12в на 12й пик у меня сразу и подавалось с ключа, потому то и возникли вопросы - ведь все вроде как должно работать, а неработало...

Дык и я про то ж... А должно со стабилитрона, т.к. PIC12Fxxx совершенно не отличается от PIC16Fxxx etc требованиями к Vpp.
Чтобы исключить возможность неправильного толкования:
в используемом Вами адаптере все MCLR должны быть соединены с катодом стабилитрона Z4.

Не совсем согласен потому что так или иначе 12в будут подаваться на MCLR, поэтому особой разницы так или этак небудет. Просто если подавать с катода то меньше опасности для кристалла, тк 12в подаются через резистор.

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

может я ее сглазил?

Я не знаю, от чего Вы запитываете программатор. Если от стабилизированного источника +12В, то, согласен, разницы нет. Если же от китайского БП с недомотанным трансом и паршивеньким выпрямителем, то ой как не согласен.
Если Vpp брать непосредственно с коллектора Q5, то оно будет равно напряжению питания программатора (за маленьким минусом).
Стабилитрон Z4 ограничивает напряжение программирования. Резистор R10 при этом работает обычным резистором в обычном параметрическом стабилизаторе. И не говорите ему (резистору) ничего про спасение кристаллов, а то он возгордится и откажется работать.
Посмотрите осциллографом напряжение питания программатора - оно должно быть без просадов ниже 11 В и без пиков больше 13 В. Если это не так, настоятельно рекомендую перечитать выше- и ранеесказанное, а также ознакомиться со спецификацией программирования PIC'ов и схемотехникой входа MCLR.

в спецификации сказано , что напряжение на MCLR должно быть минимум Vdd+3,5в и максимум 13.5в
но даже если по вашему - почему тогда с другими кристаллами нет проблем??
кстати да, резистор спасает не кристалл а стабилитрон - эт я конечно ошибся.

Не знаю, какую спецификацию программирования PIC'ов Вы смотрели, но в тех, что я сейчас просмотрел, сказано:
> High voltage on MCLR VIHH min 10.0 max 13.5 V

Возможно потому, что 16f84a или 16f876a, которые у Вас читаются/пишутся нормально, Вы устанавливаете в другую панельку, на которую Vpp приходит со стабилитрона.
Я уже предложил Вам посмотреть картинки по питанию - сразу все станет ясно. И я специально указал более жесткие границы для напряжения питания, чтобы не было никаких сомнений.
Без указания характеристик питания и переделки адаптера ничего больше не скажу.

спецификация отсюда http://ww1.microchip.com/downloads/en/DeviceDoc/41191D.pdf
кроме того как я уже говорил, стабилитрон я убрал, но работоспособность с 8х осталась. Напряжение у моего блока порядка 10,5 вольт. Но даже при подаче 12 ничего не меняется к сожалению.

Угу, оказывается, обновили. По Vihh действительно указанные Вами значения. Был неправ.

Я бы как раз стабилитрон оставил - при меньшем напряжении он не мешает (ну если только у него очень пологий переход в область пробоя, и он приоткрывается при 0.7..0.8 от номинального напряжения стабилизации).

А пульсации по питанию какие? Если нет осциллографа под рукой, тогда тестером переменку измерьте - хоть какая-то среднепотолочная оценка будет.
Обратите также внимание на параметр
> TVHHR MCLR rise time (VSS to VHH) for Programming mode entry max 1.0 μs
По Vpp стоит C13 1nF, который может затягивать фронт Vpp сверх допустимого. Соответственно, можно попробовать уменьшить/убрать этот конденсатор.

незнаю что в моем блоке насчет пульсаций, но в нем диодный мост+1000мкф+стабилизатор на транзисторе.

стабилитрон и в самом деле пусть стоит

конденсатор убрал - непомогло...

ж**а какаято... у меня все больше подозрений что не та фаза луны...

Мдя, на питатель можно не грешить.
Качнул ICProg. Выдержка из хелпа:

Почти про фазы Луны.
Сейчас более внимательно посмотрел на схему основной платы программатора, чтобы попытаться понять, как он может управлять Vcc.
Резюм: пытаться управлять Vcc (в опциях программы) можно только с внешним источником. Чтобы все было более-менее корректно, нужно "+" C3 перенести с JP2.2 на JP2.3 (непосредственно на вход стабилизатора). Я бы еще добавил ключ для принудительного разряда C4, т.к. неизвестно, на какое время ICProg снимает Vcc - самостоятельно PIC будет долго разряжать 47 мкФ.

вот еще выдержка из хелпа к винпику:
Programming a PIC16F84 works, but programming a 16F628 does not work with my programmer - why ?
There is a major difference in the programming specifications. Most newer devices require a very fast rise on Vpp and / or Vpp (less than 50 microseconds between them) which is impossible with some of the "extremely simple" programmers I have seen on the web. The problem is, if the PIC starts executing its code because Vdd (the supply voltage) is present, but Vpp (the programming voltage) is not raised to say 12 Volts fast enough. So the program counter will not be zero when entering programming mode, and programming will fail for this reason. Get or borrow a two-channel oscilloscope and measure these voltages. If there is a slowly rising edge on the Vpp pin, throw those large electrolyte caps out to make the rise time faster. Or, invest a few pennies / cents for a few transistors and build a better interface.
There is a workaround for this problem when using the JDM programmer: WinPic sets all control lines HIGH for about 500ms, which should discharge all capacitors, before applying the Vpp voltage. I tried this successfully with a PIC12F675, where the MCLR-input had been disabled previously, and had no problem when trying to overwrite the chip. If this doesn't work with your JDM programmer, let me know, maybe making the 500ms discharge interval even longer helps. About the JDM programmer and oscilloscopes: DO NOT CONNECT THE OSCILLOSCOPE TO THE PIC'S GROUND - the scope's ground will most likely be connected to the PC's ground, which causes a short circuit for the JDM programmer's tricky supply voltage !

это типо транзистор пошустрее надо, поскольку конденсаторов то нету. Или както управлять питанием +5в...

Проблема в этом "MCLRDIS" при внутрисхемном программировании надо разрешать ногу сброса. иначе она первый раз программируется как порт ввода/вывода и приприповторном программировании (и при первойже верификации) на неё подаётся напряжение VPP (+12В) и эта нога порта (если не ошибаюсь RA3) выгорает, а возможно и ещё что-то

На основной плате программатора по схеме стоят два электролита по 47 мкФ (C4 я бы вообще заменил на керамику 0.1-1 мкФ).
Более шустрые транзисторы в ключах не требуются - если оставить C3 там, где он нарисован в схеме, время открывания ключа на Q6 будет определяться временем заряда C3 от линий DTR, RTS и, может быть, TXD COM-порта. Время закрывания - разрядом C3 через R8/базу Q4. Поэтому я и сказал, что
С внешним питанием и JP2 в положении 1-2 оболочка может попробовать как-то поуправлять Vcc.
В 41191D.pdf не нашел подтверждения выделенному во фразе

Сверху нормируется только параметр TVHHR - время нарастания MCLR (от VSS до VHH) для входа в режим программирования - не более 1мкс. Я про это уже писал.
Интервал между подачей Vpp и Vcc и время нарастания Vcc никак не ограничивается.
Но предложенный метод исследования проблемы (двухлучевым) бациллоскопом скорее всего позволит выяснить ее причину. Если соберетесь этим заняться, не забудьте про:

MCLR может работать только как вход. Защитный диод на нем стоит только на землю
Нажмите для просмотра прикрепленного файла
в отличие от других ног
Нажмите для просмотра прикрепленного файла
Внутрисхемное программирование накладывает некоторые ограничения на смехотехнику самого устройства и не более.
Не лучше ли прочитать внимательно документацию, чтобы не было сомнений про "возможно и ещё что-то"?

У меня длинный кабель программатора - около 70 см. Возможно это искажает форму сигнала.

Что я заметил, поскольку изначально мой программатор сделан под понипрог, я попробовал проверить что он делает с питанием при программировании. Так вот понипрог на некоторое время отключает питание когда начинает программирование, а другие проги - нет. В схеме програматора 3 линии в паралели управляют питанием Vdd, а так ими управлять очевидно умеет только понипрог. Так что может быть стоит попробовать на управление питанием пускать только один канал и соответственно настроить ево в программе (в частности винпик может управлять Vdd). Может это поможет.

Все, наконец получилось. В спецификации показан порядок захода в режим программирования: сначала подается Vpp, потом Vdd, потом все остальное. Что я сделал - в схеме для понипрога убрал диоды d2 и d1 идущие на кондер с3, оставил только d3. Это дало то, что подачей питания управляет только сигнал подачи Vpp. Но поскольку Vpp нарастает мгновенно (нет никаких конденсаторов) а на Vdd стоит конденсатор (с3 и с4), то Vdd подается с задержкой. Только пришлось увеличить с3 до 1000мкф (кстати и переставить его на вход u3), потому что при записи памяти-еепром-битов идут пропуски Vpp, и мелкий конденсатор быстро разряжался и выключал кристалл, всвязи с чем неудавалось запрограммировать биты настроек.

Вобщем с 12f6xx похоже ясно все, только теперь меня немного смущает, что возникли проблемы с другими кристаллами, в частности с 16f876a. Для него похоже питание надо подавать раньше чем Vpp, иначе он не опознается программатором (винпик800). Однако есть интересная фишка - если два раза подряд без паузы нажать в нем распознавание процессора - первый раз нераспознает а второй распознает. Я так понял, что 1000мкф просто не успевают разряжаться и процесс распознавания проходит правильно.

Но это меня неочень радует, надо думать чтото еще.

Спасибо всем, в частности xemul за советы.

С нового PIC (если есть калибровочная RETLW OSCCAL в последней ячейке CODE) нелишним вычитать, написать на кусочке самоклейки-ценника, и приклеить прямо на него снизу.

Все нормальные программеры не стирают у таких PIC RETLW OSCCAL.
Пользуюсь EPIC. Еще ни разу не остался без родной RETLW OSCCAL.

Пользуюсь схемой программатора предложенной Елисеевым на телесистемах....и маленько переписанным софтом (altprog) - благо исходники он любезно предоставил. Из более 100 штук проколов не было. А все разговоры про покупные программаторы - долгая и бесполезная полемика ибо рассматривать надо всегда конкретную задачу и конкретный кристалл.

Где посмотреть можно схему