Заметил такую ситуацию. На старте пишу в P2.0 значение 0, затем во время работы его программно не трогаю. Какое-то время после старта там нах-ся 0. Этот пин, кстати, выведен на разъём программирования (двухпроводный). И периодически тыкаясь на этот пин тестером наблюдаю, что он перескакивает (от помехи/прикосновения тестера возможно) в 1 и так и держится до конца. Вся остальная прога при этом отлично работает. Этот пин ни в схеме ни в проге не заюзан.

Собственно вопросы:
1 Как объяснить такое поведение пина/порта.
2 Отличается ли этот пин/порт от остальных (P0 и P1) внутренней схемотехникой и помехонеустойчивостью? Из этого следует насколько вероятны искажения других пинов/портов.
3 Юзал ли кто-то P2.0 для вывода/ввода обычных цифровых сигналов в схемах и не сталкивался ли с какими-то особенностями/странностями?

По поводу защиты от таких глюков идея только периодически читать порт и переписывать при несовпадении. А учитывая особенность х51 процов (чтение не внутренней защёлки, а внешнего уровня), то чтение вообще лучше не делать.

А что за проц? Линию C2D както использовал в режиме выхода. Может банальный непропай?

Проц F350. Программируется без проблем. Почти наверняка пропай.

По идее такое возможно если ядро проца останавливается (это режимы Idle и Stop) или подается ресет. В этом случае на сколько я понял пином рулит внутрисистемный дебагер.

Не. Работает моя программа и замечаний к ней нет. В программе слипа режима нет никакого. Забыл уточнить. Порт P2 настроен при этом на ОК (не пуш-пул). И в LowLevelInit в порт пишется 0 и больше он не юзается. А слетает возможно от прикосновения щупом тестера и далеко не с первого раза.

Если кому-то не лень, попробуйте у себя в девайсе так же. Будет возможность я сам на других девайсах попробую. Пока заметил только на одном, т.к. других нет под рукой.

Почитайте в документации про режим "чтение-модификация-запись". Возможно, это ваш случай.

Я вроде хорошо на память знаю особенности классического х51 по поводу чтение-модификация-запись. Каким боком этот режим может влиять на порт/пин при отсутствии к нему обращений вообще - не понимаю. Из всего программного 8-бит порта наружу выведен только один пин. К порту в программе нет обращений вообще, кроме одного на старте.

Может все таки дебагер шалит? Забывает после очередного обмена вернуть пин в исходное.

Сбои при подключенном отладчике иле нет?

Запишите в порт 1. Если будет перескакивать в 0, будете думать дальше. Если останется в 1 - забудьте.

Дебаггер не подключен. А пин кстати тот, по которому отладчик должен работать. После слёта в 1 при измерении тока с него на землю показывает 30 мка. То есть работает внутренняя подтяжка для ОК.

На него можно светодиод подключить и моргать им. Если что, то и не страшно.

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

А если поменять тестер? Эффект остаётся?

Вобщем оказалось этот пин P2.0 заколдован
Двупроводным отладочным интерфейсом. Даже светодиод на него весить ненадёжно, если потом с него "снимать" визуальные сигналы. От помех по любых пинах, земле и питании, пин P2.0 отключается от ядра и переходит в режим отладочника. При этом программно совершенно не определить, что пин отключился. Хотя в режиме входящего сигнала не проверял пока. Только на выход. Контроль всех SFR, прямо или косвенно связанных с пином P2.0 присутствует и они никак не меняются. В частности P2MDIN, P2MDOUT, XBR0, XBR1. В итоге пин до следующей аппаратной "перезагрузки" aka reset будет жить в режиме C2D (отладочный).

Продолжу тему.
Кто-нибудь видел эррату свежЕе 2004 года на F350?