Имею такую ситуацию. Запрограммированы десятки устройств на ATtiny24. Все хорошо, но в одном экземпляре наблюдается ситуация, внешне подобная очень быстрому выполнению программного кода. Устверждать, что программа выполняется в точности, но быстрее, нельзя. Установка фуза CKDIV8 приводит к замедлению, но всеравно очень быстро. Тактируется МК от внутреннего RC генератора. Умом понимаю, что работать на частоте в десятки мегагерц МК не может. Собственно вопрос: это брак МК и его можно выкинуть? У кого было подобное? МК читается м пишется без сбоев. Спасибо!

Ошибка в программе, связанная с внешними факторами.
Чудес не бывает.

Если "быстрота" как-то связана с прерываниями от внешних источников, то ищите причину в посторонних шумах.

Перепрошивал н-цать раз двумя разными программаторами. Верификация успешно.

ошибка в программе - это не значит что, что-то не так прошивается.
В той программе что Вы прошиваете что-то где-то не учтено, дребезг, шум и т.п., событий происходит больше, и со стороны кажется что МК работает быстрее.

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

Определенно брак и его определенно следует изъять из поставки.

Другое дело -- брак чего: всего девайса или только МК? Поскольку, у меня "унутре" живет экспериментатор-исследователь, то я бы поигрался с таким девайсом, прежде чем отправить его под пресс. Для начала бы записал тестовую прогу, которая программным способом генерит меандр, а далее по ходу бы искал, кто "в семье гадит".

Удачи!

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

Это может быть брак МК в части рц-генератора, а может быть и мощнейшая ошибка в программе. Обязательно нужно найти причину, не так уж это и трудно.

1) Оцените частоту задающего генератора. Напишите простейшую программку выдачи меандра на какую-нибудь ножку, запустите на подозреваемом МК и на штатном, измерьте частоту, сравните, сделайте выводы.

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

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

Пример. Из того факта что у 10 человек нету птичьего гриппа не значит, что человек не может им заразиться.
То есть это просто формальная логика - если есть N успешных тестов, это не значит, что всё устройство верно. Зато наоборот, из одного непройденного теста следует что в устройстве проблема. Вопрос в том, где.

тут надо перефразировать: одно нерабочее устройство на фоне десятков рабочих (полнофнукционально).

обнаружился еще один факт - один образец ведет себя так же, но на участке кода всегда в определенном месте. может что-то с питанием...

Ну вот видите, вам же три человека говорили, а вы упирались.

defunct Ошибка в программе, связанная с внешними факторами. Чудес не бывает.

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

=GM= Обязательно нужно найти причину, не так уж это и трудно. Оцените частоту задающего генератора. Если частоты обоих МК слабо различаются, значит, ошибка (баг, фича, грубый просчёт) в вашей программе, имейте мужество признать. Начинайте вычленять сегмент, где эта ошибка сидит.

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

[DELETED]

2 smk - всё же советую прислушаться к совету =GM= и написать простенький генератор меандра..
Не могу понять - почему такой простенький тест , который сразу расставит все точки над I вы есчё не реализовали ??