Я, в общем-то, работаю с PIC16 изредка и всегда, когда работал с EEPROM данных на запись, контролировал завершение по EEIF, как описано в даташите. А тут, для простоты и компактности, решил сделать поллингом бита WR в EECON1. И - зацикливаюсь на его опросе, как он встал в "1", так и остался (запись произошла, потом проверил). Вроде такого быть не должно, он должен по окончанию записи обнуляться ? Кто что подскажет ? Переделал пока на EEIF, но все ж странно...

Проверьте БАНК (EECON1,WR находится в BANK1).
Должно работать, всегда проверяю окончание записи по этому биту (правда, на 16F631 еще не приходилось).

Банк тот, я его не менял, поскольку только что выставлял WR в "1". У F631 это банк 3, но непринципиально... Усомнившись, не подгаживает ли вдруг обработчик прерываний, попробовал с сброшенным GIE - то же самое. Странно это...

Сразу после установки WR в 1 я запрещаю новую запись
bcf EECON1,WREN
и только потом проверяю WR.

Проверил такой вариант - не помогает. Странно...

Если уж быть совсем точным, WR я всегда проверяю перед началом записи или чтения (закончилась ли предыдущая запись). Но, вроде бы, разницы не должно быть.

В общем, есть мнение, что это глюк микрочипа. При первой записи в EEPROM может всплыть эта проблема. Лечится включением WDT. Я обычно при первом запуске программы инициализирую содержимое EEPROM. Если на первой попытке записи происходит зацикливание, то выхожу по сбросу от WDT и начинаю сначала... С какой-то по счету попытке запись все-таки проходит - WR обнуляется, а при дальнейшей работе такая проблема с записью уже не возникает... Встречаются экземпляры которые подозрительно долго инициализируют EEPROM при первом включении - по несколько секунд... Но, в конце концов, обычно все нормализуется.

А что по этому поводу "говорит" MPLAB?

На днях сам пол дня пропрыгал вокруг 690-го (они родственники). В итоге всё заработало, но куча этих переключателей банков.. Через строчку BANKSEL. Бррр..

MPLAB я не использую, но строго придерживаюсь рекомендациям в ДШ... IMHO, причина где-то в самом в железе.
Просто, первое, что обычно начинают делать, столкнувшись с этой проблемой - выискивать ошибки и править программу. Не нужно. С N-ой попытки запись заработает сама... Почему, так происходит - я до сих пор не понял.

Короче, обманул я - подгаживал все ж обработчик прерываний (очевидно, при проверке что-то не так закомментировал). А причина - проста до безобразия: я от большого ума разместил области сохранения w и status по младшим адресам RAM, а сам полез в старшие банки. Сработало прерывание и по выходу восстановило из несуществующего адреса, выставив банк 0. Ну а дальше WR можно поллить хоть до посинения. Все ж PIC16 хороши до того момента, пока можно обходиться одним-двумя банками (да и то с осторожностью), а так спятить можно...

После перехода на Си забыл о подобных проблемах. Компилятор берет на себя все вопросы с переключением банков.

Аппаратные проблемы с EEPROM компилятор Си тоже на себя берет?
Видимо, Вам туда: http://electronix.ru/forum/index.php?showt...t=0&start=0

Да берёт.... А куда нам, решим без вас )

Не нужно путать своё мнение с общим... Все глюки Микрочип расписал в ERRATA, остальное - отсебятина... Не можете разобраться с EEPROM - ваша проблема... А то что написали Вы - полный бред... Или Вам за него платят???



А зачем тогда советы давать как лечить, как с бубном плясать, если не танцор и не доктор???



И что там??? Вам туда не надо, там нет строчки "Выдумываю глюки Микрочипа с особым рвением"...

С общим мнением, свое я не путаю, высказываю только его... Но целом, вынужден признать свою не правоту. Я работал с серийными изделиями, где запись в EEPROM производилась, непосредственно, после старта программы. Видимо, проблемы с записью были обусловлены именно нестабильностью питания в момент включения... Разбираться было некогда, поэтому применили такой способ решения проблемы... Благодарю HHIMERA за критику, для меня она была очень полезна....