Вообще, должен после прошивки вычитывать код из проца и сверять побайтно.
Вообще, должен после прошивки вычитывать код из проца и сверять побайтно.
Спасибо от Палыч
Да наверное так! Но как оно работает - вопрос... Можно записать байт, проверить, как записал, записать следующий и т.д. А можно все записать, а потом побайтно проверять.. И так можно...
Владимир! Ну зачем флудить?Сообщение от Владимир_К
Если есть интерес, отличающийся от темы -пожалуйста в личку. С удовольствием с Вами пообщаюсь и отвечу на Ваши вопросы.
Все там нормально. Просто программатор при считывании памяти не знает где на самом деле кончается программа и читает всю память.
Значения ячеек типа 3FFF просто остаток памяти, куда программа так сказать, не достала.
А две дополнительные строчки - это конфигурационные биты, которых в исходном файле не было.
Если Вы правильно установили значения этих битов в окне программатора, все должно работать.
Спасибо от Палыч
У меня PicKit2 сначала пишет, потом читает проверяет. Бывает выдает ошибки. Бывает даже с ошибкой проверки все-равно работает. Больше всего ошибок проверки возникало на старом компьютере, так и не смог выявить почему, отключал лишние программы чтоб освободить комп. проц. при прошивке.
Спасибо от Палыч
приветствую. как опытный "прошивальщик" смешного ничего не вижу. иедентично тому, что смеятсся на неопытным водителем.Возник вопрос: это ошибка прошивки или какая-то служебная инфо самого МП? В основном байты файлов совпадают.
PS Возможно для продвинутых пользователей микропроцессоров мой вопрос покажется смешным или нелепым, но прошу сделать скидку на то, что я еще не волшебник, а только учусь...
поясню в кратце. контроллеры из серии PIC используют 5 сигналов - DATA,CLK,MCLR,GND,VC C
обычно не вся память занята , даже в программе существуют значения ячеек 3F или FF. если появляется постоянные знаки 3F или отрезки памятик забиты , нужно проверить наличие ёмкостей на ножках CLK и DATA.
возможно так же что эти ячейки с 3F неисправны. "умный" программатор обычно не переписывает все данные по новой, а исправляет/корректирует только изменения в коде.
провода к компоненту прожигания должны быть короткими.
Спасибо от Палыч
Коллеги, спасибо всем ответившим! Для меня ситуация с прошивкой более менее прояснилась. Во всяком случае, полученной информации достаточно для продолжения своих упражнений в новой для меня области знаний.
Моя, было пошатнувшаяся вера в наше радиолюбительское сообщество, возродилась! Оказывается еще не все так плохо, если еще можно найти помощь и поддержку! К сожалению, наши ряды редеют, и кому как не нам, вымирающим динозаврамподдерживать друг друга!
Вам повезло...а тут как ни бьюсь всё бесполезно?!
Анатолий!
Не сочтите за менторство, но чтобы воспользоваться коллективным разумом форума стоило бы формализовать проблему. Правильно поставленный вопрос это половина ответа. Не в обиду будь сказано, но из Вашего поста, описывающего проблему, суть проблемы не понятна...
Если хотите, давайте пообщаемся в личке и сформулируем проблему.
В любом программаторе есть опция проверки (verify) того что вы хотите залить с тем, что залилось. И если оно проходит, то скорее всего процессор живой.
если вы посмотрите на картинку в посте #9 (взял для примера, поскольку уже есть тут) то увидите ряд кнопочек в верхней половине картинке - там есть такая кнопка - Verify. У вас в вашей программе есть что подобное.
Последний раз редактировалось er1mf; 17.01.2015 в 01:56.
Для ТС - в большинстве случаев, если программа записи завершила прошивку без ошибки, то есть надежда на успех
некоторое пояснение:
При формировании hex-файла для пик-контроллера компилятор вписывает только необходимые строки адресов/команд/данных/фьюзов, незадействованные ячейки не включаются в файл.
Программатор же, при считывании контроллера, наперёд "не знает" по каким адресам лежит значимая информация и считывает всё подряд.
В приведенном hex-файле использована почти вся память программ контроллера, поэтому разница в размере файлов мала и не бросается в глаза.
Если бы программа была короткой, то разница в размерах записанного и считанного hex-файлов была бы заметно больше.
У hex-файлов, созданных программатором при считывании МК, размер полный (память программ, память данных, фьюзы) , а у файлов, созданных компилятором, он меньше и соответствует фактически задействованному объёму информации (например, если память данных не важна, то она и не пишется в hex).
-----------------------------
Резюме:
Посимвольно сравненивая hex-файлы компилятора и программатора, нельзя сделать вывод о совпадении/различии содержимого МК.
Мало того, hex-файлы, созданные разными программаторами/ПО при считывании одного и того же МК могут различаться.
Если hex-файлы, считанные одним и тем же программатором из разных микросхем, совпадают, то есть надежда (конечно, если не установлены биты защиты
Hex-файлы оставляют некоторую неоднозначность написания, поэтому для сравнения содержимого разнообразных микросхем я предпочитаю, когда это возможно, более жёсткий bin-формат.
Для микрочипов (например, в отличие от атмелов) это удобно, т.к. вся информация лежит внутри одного bin-файла (есть, правда, "ложка дёгтя", связанная для некоторых типов PIC-МК с их калибровочными константами).
Т.ч. не переживайте - всё хорошо!
Успехов в дальнейшем изучении МК!
Последний раз редактировалось Veka; 17.01.2015 в 04:12.
Спасибо от Палыч
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
