Форум РадиоКот

Помогите пожалуйста.

Для прошивки пользуюсь китайским USBAsp и программой SinaProg 2.1.
До вчерашнего дня все шилось хорошо без проблем.

Вчера что-то сломалось

Чистую микруху он определяет и даже прошивает, но после этого микруха омертвляется (фьюзы не читаются, тип не определяется) при чем при любом действии SinaProg пишет что все хорошо.

Иногда если много раз нажимать ChipErase микруха возвращается к жизни.

Прошивальщиков у меня два с обоими симптомы идентичные, т.е. проблем похоже софтверная.

Подскажите что могло случиться, на компе ничего не менялось.

Винда Семерка. Обновление конечно накатываю периодически.

Прошивальщиков у меня два

В переводе на русский 2-а программатора ? Если да, тогда самое простое проверить на другом компьютере...
Или сделать откат виндоуза на день два назад.

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

Прошивальщика два - да два программатора.

Я тоже подумал откатить винду - вечерком сдлаю, но пока честно говоря не укладывается как обновление винды могло повлиять.
Поэтому надеюсь еще на какие-то предположения.

LeonOn1 писал(а):
Чистую микруху он определяет и даже прошивает, но после этого микруха омертвляется (фьюзы не читаются, тип не определяется) при чем при любом действии SinaProg пишет что все хорошо.

вот это не понятно. Как вы определяете, что она "омертвляется", если Сина говорит, что все хорошо, да еще и пр "любом действии"

Если на программаторе есть возможность уменьшить частоту, то следует попробовать.

ozonn писал(а):вот это не понятно. Как вы определяете, что она "омертвляется", если Сина говорит, что все хорошо, да еще и пр "любом действии"

Ситуация такая: ставлю новую микруху нажимаю например считать фьюзы - они считываются, залить прогу - прога заливается.
1. После заливки проги нажимаю считать фьюзы - он пишет везде нули при этом в статусной строке SinaProg пишет что все ок - типа считал фьюзы - но на самом деле не считал.
2. Пытаюсь залить другую прогу - заливаю - SinaProg пишет что все ок прога залита, а на самом деле там старая прога в микрухе.
3. Пытаюсь определить тип микрухи - тип остается то что был выбран в выпадающем списке (не соответствует действительности) при этом SinaProg пишет что тип успешно определил

LeonOn1 писал(а):

ozonn писал(а):вот это не понятно. Как вы определяете, что она "омертвляется", если Сина говорит, что все хорошо, да еще и пр "любом действии"

Ситуация такая: ставлю новую микруху нажимаю например считать фьюзы - они считываются, залить прогу - прога заливается.

ну, а после "заливки" "проги", эта самая "прога" выполняется контроллером? Может дело в "проге"?

Драйвер для "прошивальшика" переустановить пробовал?

nikin_n писал(а):Драйвер для "прошивальшика" переустановить пробовал?

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

Удалить - в диспетчере устройств , при подключенном программаторе.. правой кнопкой - драйвер - свойства - удалить (удалить файлы..)

Более менее разобрался с ситуацией.
В прогу в начало вписывал инструкции, чтобы такты не делились на 8
--
CLKPR=0x80;
CLKPR=0x00;
--
Таким образом я изменяю частоту и прошивальщик как-то не правильно начинает работать.
Т.к. это только инструкция в программе она не имеет фатальных последствий и если прошивальщик успевает сразу после ресета начать прошивку то все ок, прога в микрухе меняется - это и объясняет нестабильную работу - то работает то нет

Вторая ситуация хуже. В результате эксперементов стал менять FUSE CLKDIV8. И в этом случае микруха уже точно не прошивается.
Погуглил на эту тему, написано что нужно снижать скорость прошивки до 8 КГц, меняю настройки в SinaProg - но без эффекта.
Опять же погуглил вроде как не все китайские USBAsp поддкрживают низкую скорость. Вроде как там должен быть джампер.

Подскажите плиз по прошивальщику можно ли как-то малой кровью (дровами, прогами) решить этот вопрос или только перепрошивкой самого прошивальщика?

мк какие именно? было похоже на 8ой меге

Запись CLKPR влиять не должна, т.к. при входе в режим программирования контроллер сбрасывается и до выполнения этой программы не доходит (именно поэтому я ЗА такой метод изменения делителя!), а вот прошивка фьюза CLKDIV8 изменяет делитель сразу, до запуска контроллера, независимо от режима. Тактовая частота программатора должна быть в 4 раза меньше тактовой частоты контроллера, поэтому увеличением тактовой частоты контроллера через CLKDIV8, хуже по идее сделать нельзя. Возможно стоит попробовать другую оболочку, которая честно будет ругаться на неправильную сигнатуру, а не говорить что "вот, я такую прочитал и она нормальная - 00 00 00". Если есть осциллограф можно встать на MISO и посмотреть какая там на самом деле сигнатура приходит, а то, может программатор даже не вводит контроллер в режим программирования...

Engineer_Keen писал(а):Запись CLKPR влиять не должна

Есть удаленный опыт. Установив для теста CLKPR на максимальное деление, программатор потерял МК и увидел только на медленной частоте программирования. Какая тут связь непонятно , наверное нюансы китайских программаторов.

Вот блин... Зачем я полез экспериментировать, чуть не пришлось контроллер выпаивать. Поставил делитель программно на 256 и досвидос... AVRISP II из студии контроллер потерял. В голове не укладывается такая логика, но похоже это действительно так. Каким-то чудом команда chip erase пролезла в контроллер, и я его "починил". Это может говорить о том, что в какой-то момент времени контроллер все-таки можно ввести в режим программирования, не смотря на то, что делитель установлен программно

Можно попробовать нажать RESET ручками и отпустить одновременно при нажатии кнопки стереть. По факту попытаться отпустить резет максимально одновременно, но позже команды стирания.

У меня с STM8 подобная заморочка была, МК конечно другой и протокол программирования тоже. Но данный "ручной" алгоритм помогал. Что интересно. Пользуясь одним и тем же программатором из среды STVD мк терялся через раз, из IAR крайне редко. Если нажать ручкам резет и не отпускать, а затем стереть, обе среды тупили вроде около пары секунд и только потом выдавали ошибку. Видимо обе среды ждали ответа долго. А если резет не нажимать ручками, то МК отвечал видимо какой-то лабудой из-за успевшей запуститься прошивкой. По скольку в IAR такого почти не происходило, то видимо в нем реализованы более точные тайминги для камня. Хотя STVD от разработчика камня. А может из-за китайского клона ST-LINK V2.

Я к чему про STM, может и с AVR какая-то подобная непонятка.

Была мысль ресет руками зажать, но программатор ожидаемо ругается на КЗ, а поймать момент между отпусканием и началом программирования, нереально...

Ага. Дурной совет, который прокатил на другом МК. Только у меня с USBASP мк хорошо верифицируется с зажатым резетом .

Снял временную диаграмму верификации USBASPом Атмеги8.

Если я правильно понял,а это не факт, чтобы войти в режим программирования, программатор должен подать питание когда RES и SCK на нуле. А так как это не всегда можно сделать, то необходимо дать положительный импульс не менее чем на два такта. Мой программатор и sinaprog сделали это с хорошим запасом -10 мс.

Apply power between VCC and GND while RESET and SCK are set to “0”. In some systems, the
programmer can not guarantee that SCK is held low during power-up. In this case, RESET must be
given a positive pulse of at least two CPU clock cycles duration after SCK has been set to “0”.

Видимо, пока положительный импульс, зашитая программа успевает что-то сделать, за 10 мс много можно сделать. И в любом случае успевает изменить OSCCAL. Приходит спад RESET, МК уходит в режим программирования, а OSCCAL остался в установленном значении. Видимо регистры инициализируются в момент снятия RESET. Генератор работает на малой частоте,и SPI уже не может поддерживать быстрое программирование.

Выводы, возможно не совсем верные:
1. Нужен программатор который умеет подавать питание, после того как установлен резет и клок в ноль.
2. Или нужен программатор умеющий программировать на низкой частоте.
3. Или перед понижением частоты генератора, надо потупить более 10 мс (в моем случае). Я про прошивку целевого МК.

Из руководства AVRISP mkII.

Это означает, что для тактовой частоты программируемого микроконтроллера менее 12 МГц, частота
ISP должна быть равной или меньшей 1/4 этой частоты.
Для тактовой частоты микроконтроллера выше 12 МГц, частота ISP должна быть равной или
меньшей 1/6 этой частоты.
Обратите внимание, что для микроконтроллеров с конфигурационным битом CKDIV (Clock Divide –
деление частоты) и/или с CLKPR (Clock Prescaler Register – регистр предделителя тактовой
частоты) частоту ISP необходимо вычислять из частоты, получаемой после делителя.
...
Примечание: AVRISP mkII не поддерживает программирование Flash или EEPROM на частоте ниже
2 кГц. Однако полное стирание устройства будет работать вплоть до частоты 51 Гц. Если из-за значения
в регистре CLKPR частота микроконтроллера настолько низка, что он не программируется, то перед его
программированием выполните полное стирание устройства

Вообще ситуация странная, ведь когда я выставляю в проге
CLKPR=0x80;
CLKPR=0x00;
Это значит что частота увеличивается. В моем случае использования тиньки 2313 = 8 МГц
Тогда почему прошивальщику не удается прошить, может у него обратная ситуация он не может на такой высокой частоте прошить?

Но эксперементально получается что ресет помогает. На бредборде поставил кнопку между землей и ножкой ресет. После выставления CKDIVили CLKPR жму много раз одной рукой на очистку миркухи а другой на кнопку ресет - через несколько попыток все стирается.

Т.е. остается конечно вопрос, почему когда частоту микрухи увеличиваю перестает нормально прошиваться?
И есть ли где-то на прошивальщике этот самый джампер на пониженую частоту или надо например прогу не SinaProg использовать
Дрова версии 1.2.6
SinaProg 2.1