Форум » Программирование микроконтроллеров. » Неожиданная проблема!!! » Ответить

Неожиданная проблема!!!

Deputat: Сегодня при попытке зашить в PIC16F628 HEX-файл(скачал из интернета), программа WinPic800 выдала ошибку записи и контроллер перестал быть работоспособным. Когда пытаюсь его прочитать, выясняю, что все области памяти забиты нулями. Записать ничего не могу, т.е. PIC похоже накрылся. Программатор абсолютно исправен. Дальше вообще интересно. Все подозрения падают на файл прошивки. Взял другой PIC 16F628 из работающего устройства и "убил" его при попытке зашить тот-же HEX файл. Затем взял третий PIC, абсолютно новый, еще не прошивался и без проблем залил его одной из своих старых прошивок,все стер и опять зашил, все отлично. Скажите, возможно ли убить PIC программно?

Ответов - 46, стр: 1 2 All

Evgeny Korabelnikov: Бит защиты может выставляться программно (в слове конфигурации). Не исключено что Вам попалась такая "бяка". Если это так, то за ПИК не беспокойтесь. Просто нельзя будет считать записанное и снять в программаторе бит защиты (снимается в программе). Другие HEX файлы, без установленного программой бита защиты, должны читаться.

Deputat: Пробовал заливать другую прошивку, сразу выдает ошибку записи по адресу 0x0000h. Да и в исходном HEX файле бит защиты не установлен.

Deputat: Вот ссылка на архив с "проблемной" прошивкой, там лежит и asm-файл http://www.shema.ru/12/ds1990a.zip


Evgeny Korabelnikov: Лично я с такой "бякой" никогда не сталкивался, но факт наталкивает на размышления. Имеется такая версия, (лучше хоть какое-то объяснение, чем никакого): В слове конфигурации задан внутренний RC генератор, который начинает работать в ходе процесса программирования (после конфигурирования). Получается, что в процессе программирования начнет, пусть и через "пень-колоду", но отрабатываться та часть программы, которая уже прошита. При этом возможны различные "бяки" (электрические конфликты) в части касающейся тех сигнальных выводов, которые задействуются при прошивке. В данном случае, их последствия зависят как от конкретной программы, так и от конкретного программатора (от нагрузочной способности его аппаратной части). Думаю, что если бы задействовался кварцевый генератор, то проблем не было бы, так как, из-за отсутствия кварца (при прошивке), исполнение программы невозможно.

Deputat: Не пожалею еще одного PICа, но все же попробую найти истину. Очень уж любопытно. Сколько писал программ, в том числе и с внутренним RC генератором, проблем при программировании не было. Впервые попробовал зашить "чужую" программу, и вот вам сюрприз!!!

Evgeny Korabelnikov: Андрей, успехов. Было бы любопытно узнать, "в чем тут собака прылась". Случай очень интересный.

Deputat: Евгений Александрович, Большое Спасибо, вы оказались правы (опыт дает о себе знать). Выставил в слове конфигурации кварцевый резонатор и прошивка прошла успешно. Собрал устройство, все работает. Учитывая то, что в последнее время я писал несколько программ с использованием внутреннего RC-генератора и проблем не возникало, то нужно проанализировать код вышеупомянутой программы с целью выяснить конкретно то место, где возникает критическая ситуация. У меня есть большие подозрения, что конфликты могут возникать уже сразу после конфигурации портов ввода-вывода. Возможно имеет смысл врезать подпрограмму задержки в самом начале программы.

Evgeny Korabelnikov: Вариант: шить нужно с настройкой на работу от кварцевого генератора, а затем восстановить RC. Думаю, что через это, для перестраховки, нужно "протаскивать" все программы, в которых включен внутренний RC генератор. Если есть только HEX файл, то можно воспользоваться дизассемблером. Либо вообще перейти на кварцевый генератор. Спасибо за информацию. "Положил в копилку". В практическом отношении, очень ценная информация (и деньги экономит, и с нервами все в порядке).

Алексей: Evgeny Korabelnikov пишет: Думаю, что через это, для перестраховки, нужно "протаскивать" все программы, в которых включен внутренний RC генератор. Интересно, как вы себе это представляете? Насколько я понимаю невозможно изменить только биты конфигурации, не стирая всю память. Или вы нашли способ это сделать, или я чего то не понял? Были точно такие же проблемы с перепрошивкой 16ф675, работающего от внутреннего генратора, но проблема почти всегда решалась полным стиранием памяти контроллера, изрдка не помогало вообще ничего, думали что пик убили, но полежав немного он начинал шиться и работать как ни в чем не бывало...

Алексей: Deputat пишет: Не пожалею еще одного PICа, но все же попробую найти истину. Очень уж любопытно. Сколько писал программ, в том числе и с внутренним RC генератором, проблем при программировании не было. Впервые попробовал зашить "чужую" программу, и вот вам сюрприз!!! А в битах конфигурации случаем не выставлен ли внутренний сигнал MCLR? Если да, то вот и проблема. Лаб от этом честно предупреждает, что не поддерживает программирование с этой конфигурацией(внутренний генератор и внутренний MCLR.), либо измените биты конфигурации, либо шейте на свой страх и риск, остальные проги просто молча выдают ошибку иногда.

Пётр: Алексей пишет: А в битах конфигурации случаем не выставлен ли внутренний сигнал MCLR?... Думаю что это ещё зависит от программатора. Такое может случится если программатор управляет только напряжением +12, а +5 постоянно поступает на программируемый ПИК. Если программатор управляет этими напряжениям, причём сначала подаётся +12, а затем +5, то ПИК не может перейти в рабочий режим во время программирования вне зависимости от конфигурации.

Alberto: Вчера тоже прошил один ПИК приведенной выше программой и... все правильно, ПИК перестал стираться, программироваться и т.д. Т.к. ПИК по идее уже был убит, то я решил провести эксперименты дальше для чего воспользовался программой F_prog и программатором собранным по схеме с сайта http://pic16f84.narod.ru/ (кстати данным программатором старой версии я пользуюсь до сих под вместе с программой WinPic800) и все восстановилось: ПИК начал писаться, читаться и т.д. Если ПИКи еще не выброшены, попробуйте восстановить их таким путем. Так что ПИК не спален.

Deputat: Спасибо Alberto, я давно пользуюсь этим программатором. PIC-и я не выбрасывал, а тоже сегодня экспериментировал. Оказалось, что при программировании хоть и выдавалась ошибка, но программы зашитые в них полностью работоспособны. Все 3 якобы "мертвых" PIC-а отлично работают в схеме без кварца. Еще интересная штука. В программе IC Prog есть возможность запрограммировать только конфигурацию, я это делаю выставив 3F14, читаю содержимое памяти и "О! Чудо!" вместо нулей вижу код зашитой программы. Но опять же не могу ее ни стереть, ни записать что либо другое. Дальше еще интересней, закрываю программу, открываю, читаю память PIC, везде нули. Сейчас попробую воспользоваться F_Prog, когда-то давно ее использовал.

Evgeny Korabelnikov: "Насколько я понимаю невозможно изменить только биты конфигурации, не стирая всю память". Это относится к битам защиты. Попробуйте следующее: 1. Открываете в IcProg105 любой HEX файл под PIC16F628 (со снятым битом защиты). Допустим, что установлено IntRC CLKOUT (или что-то другое, не важно. Важен принцип). 2. Щелкаете по "Осциллятор" и выбираете в списке, например, XT. 3. Далее шьете все это "безобразие" в ПИК (программировать все). А можно сначала записать слово конфигурации, а затем "шить все", но зачем нужны лишние "телодвижения"? 4. Считываете то что записали (читать все) и убеждаетесь, что запись произошла и считалось не IntRC CLKOUT, а XT. 5. Теперь работаете только со словом конфигурации. В окошке "Осциллятор" меняете XT на IntRC CLKOUT. Производите запись только слова конфигурации ("Команды" – "Программировать конфигурацию"). 6. Считайте (читать все) и убедитесь в том, что и сама программа "никуда не пропала", и выставлено IntRC CLKOUT. При таком "раскладе", текст программы не нужен. Нужен только HEX файл. А запись основной "массы" будет произведена с XT. Времени для этого нужно совсем не много.

Deputat: Согласен, все симптомы похожи на установленный бит защиты, хотя в слове конфигурации на это нет и намека. Еще раз благодарю Alberto, действительно программа F_Prog смогла качественно стереть память PICа и он стал абсолютно работоспособным. Это камень в сторону IC Prog и WinPic800, которые слишком уж расхваливают. Но и в F_Prog есть недостатки. Хочу поблагодарить всех, кто откликнулся, за участие в обсуждении данной темы. Отдельная благодарность Евгению Александровичу за те знания, которые он мне дал (я имею ввиду самоучитель). P.S. Все же тема остается открытой, т.к. осталось много вопросов. Не буду будоражить общественность своими идеями и предположениями, но с удовольствием поделюсь конкретными результатами.

Alberto: Deputat пишет: Но и в F_Prog есть недостатки. например свободно распространяемая версия не шьет 877-ой ПИК, а заплатить себе дороже выйдет. Но во всем остальном мне WinPic800 нравится. Хотя надо бы разобраться как это автор умудрился так хитро защиту выставить. Просто и красиво.

Пётр: Alberto пишет: например свободно распространяемая версия не шьет 877-ой ПИК, а заплатить себе дороже выйде А зачем? Если интересно, дам прогу, которая позволяет включать недоступные пункты меню и кнопки в разных прогах. Alberto пишет: Хотя надо бы разобраться как это автор умудрился так хитро защиту выставить Защита только в том, что некоторые пункты меню неактивны (сделать очень легко), а если их сделать активными, то и демо-версия шьёт 877-ой ПИК

Deputat: Например, какие пункты не активны?

Пётр: Deputat пишет: Например, какие пункты не активны Выберите например, PIC16F873 и увидите. В общем записать в такой ПИК ничего нельзя, поскольку это демо-версия. Как решить эту проблему я написал выше.

Alberto: Alberto пишет: хитро защиту выставить. это про ПИК. Обычно защищенная м/с стирается без проблем, а здесь есть еще какие-то нюансы... Пётр пишет: Если интересно, дам прогу, в хозяйстве все пригодится , спасибо.

Dmitry Dubrovenko: Никто не упомянул одну особенность программирования. А именно, что существуют два способа перевода МК в режим программирования: 1. При включённом Vcc, поднять напряжение Vpp от нуля до 12V, 2. При выключенном Vcc, поднять напряжение Vpp от нуля до 12V, а затем подать Vcc. Для 628 как-раз рекомендуется второй способ, а, как ни странно, многие программаторы его не реализуют, хотя доработка плёвая. Поэтому полагаю, что это ещё зависит от программатораЯ столкнулся с этим, когда стал собирать EXTRA-PIC (где-то тут, на форуме, есть тема). Сейчас, в "Радио" вышла статья. Ссылки у меня на сайте. Аошибку записи по адресу 0x0000hочень напоминает попытку верификации после программирования, при включённом бите защиты. Поэтому, я, при программировании (пользуюсь IC-Prog'ом), включаю только "верификацию при программировании", а "верификацию после программирования" отключаю.

Starina48: Можно присоединиться? После последней разборки прошло почти пол года, а проблема осталась. При прошивке 628 на программаторе Pony Prog в режиме внутреннего генератора невозможно проверить, что зашито. Единственное, при снятии галочки "проверка после программирования" приходится верить сообщению "успешно…" а главное, при перепрошивке вообще зашить ничего нельзя. Выдается ошибка по адресу 0. Видимо при подаче питания включается внутренний генератор. Опробовал все предложенные выше рекомендации, кроме старого программатора , - ничего не помогает. Стираю контроллер, выдается сообщение "Стерто", ставлю его в схему, генератор работает. Пробовал стирать на Extra Pic , стираются случайным образом, без всякой системы 2 контроллера из 5. Остальные больше не перепрограммируются. Видимо придется дорабатывать Extra Pic. Кто нибудь за это время опробовал его доработку?

Deputat: Deputat пишет: Вот ссылка на архив с "проблемной" прошивкой, там лежит и asm-файл http://www.shema.ru/12/ds1990a.zip Информация к размышлению. В этом asm-файле закомментировал команду SLEEP (где-то в начале программы) и все стало нормально читаться и стираться. А вообще в последнее время пишу программы для 628 только с использованием внутреннего генератора и никаких проблем не возникает. Собираю Extra Pic из Радио №8 2007. На следующей неделе опробую.

Starina48: Очень интересно, каковы будут результаты.

Deputat: Сегодня наконец-то собрал и опробовал программатор ExtraPIC из Радио №8 2007. Сразу же решил протестировать его с вышеупомянутой "проблемной" прошивкой. Довожу результаты теста. 1) В режиме когда напряжение питания +5V всегда присутствует на PIC проблема сохраняется. Программа зашивается в PIC и он даже работает в устройстве, но его невозможно ни прочитать, ни стереть. 2) В режиме когда сначала подается напряжение программирования +12V, а потом +5V все отлично работает, читается, стирается и т.д. Так что, все стало на свои места, проблема снята. Выражаю свою Благодарность Дмитрию Дубровенко за ExtraPIC.

Starina48: Вот это приятное сообщение. Тоже приступил к его изготовлению.

Deputat: Отличный программатор. Я очень доволен.

Dmitry Dubrovenko: приступил к его изготовлениюЧитайте сообщение в теме про программатор.

dosikus: Уважаемые, работая с 628 не забывайте о фузе LVP ! Переводящий пик в режим низковольтного программирования, и если у вас программатор не вешает RB3 на землю ни читаться ни стираться он не будет.....

Dmitry Dubrovenko: dosikus пишет: вешает RB3 на землюКстати, в Extra-PIC'е (и в моей доработке в частности) это предусмотрено. А вообще, это надо умудриться...

dosikus: Да чуть не забыл , вешать он должен через резистор 50- 100 ом .

Dmitry Dubrovenko: dosikus пишет: через резистор 50- 100 ом А не больше? В моём - 1кОм.

dosikus: Пробовал не получалось снять фуз , начало снимать только с 100 ом . Может это только у меня ???

Dmitry Dubrovenko: dosikus пишет: Пробовал не получалосьЧестно признаюсь, не пробовал. Но в какой-то доке читал, что примерно такой номинал.

Михаил: У меня непонятки с аппаратной хитростью описанной в самоучителе (часть2 стр.31). Я имею ввиду загрузку данных в регистр INDF через регистр W при вычисляемом переходе. Согласно самоучителю в порте b должно быть число 170 «10101010» (см. ниже ), а лежит там 15 «00001111». Наличие нулей и единиц на выводах порта b проверял светодиодами на двух пикушках. Результат был один и тот же. У кого-нибудь есть какие соображения по этому вопросу? LIST p=16F84A __CONFIG 03FF1H indf equ 00h status equ 03h fsr equ 04h trisb equ 06h portb equ 06h ;****************************** f equ 1 w equ 0 ;****************************** org 0 bsf status,5 clrf trisb bcf status,5 movlw .170 movwf .15 movlw .15 movwf fsr movwf portb tyu goto tyu end

Алексей: Михаил пишет: movlw .170 movwf .15 movlw .15 movwf fsr movwf portb tyu goto tyu Ну, все правильно, и будет в порту число 15, вы же сначала в аккумулятор записываете 170 и перекидываете в регистр по адресу 15, потом в аккумулятор кидаете константу 15 и пишете ее в FSR, а следующим и в порт б. Насколько я понимаю вы сейчас осваиваете косвенную адресацию, и вы забыли про регистр INDF movlw .170 movwf .15 movlw .15 movwf fsr movfw INDF movwf portb Вот сейчас в порту у вас будут желанные 170...

igor: [pre2]У Алексея, строчку movfw INDF заменить на movf INDF,W[/pre2]

Пётр: igor пишет: У Алексея, строчку movfw INDF заменить на movf INDF,W А зачем? movfw это псевдо инструкция, которая расшифровывается как movf F,W

igor: Не люблю я эти синонимы. Если они не облегчают.

Алексей: Но ведь работает, и набирается побыстрее. Может не стоит указывать на такую фигню? Если бы это не работало, тогда другое дело...



полная версия страницы