Доброго времени суток.
pic16lf876a не идет запись во встроенный EEPROM. Компилятор HT-PICC, частота 1MHz (XT), питание 4В. Чтение возвращает 0xFF. Копировал алгоритм записи в EEPROM из даташита, использовал макросы из родного хидера, менял напряжение питания. Все бесполезно.
Полная версия этой страницы: EEPROM в pic16lf876a
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Все остальные микроконтроллеры
МПЛаб достаточно честно симулирует работу с ЕЕПРОМ.
Цитата(xemul @ Aug 1 2011, 16:55) 
МПЛаб достаточно честно симулирует работу с ЕЕПРОМ.
В МПлаб и протеус все работает, не работает в железе.
"Доктор, у меня это!!!"
Запишите ЕЕПРОМ программатором и прочитайте её потом контроллером в УАРТ.
Сделайте запись с проверкой и лейте диагностику в УАРТ (или хотя бы мигайте лампочкой).
Или к телепатам.
Запишите ЕЕПРОМ программатором и прочитайте её потом контроллером в УАРТ.
Сделайте запись с проверкой и лейте диагностику в УАРТ (или хотя бы мигайте лампочкой).
Или к телепатам.
Цитата(xemul @ Aug 1 2011, 18:26)
"Доктор, у меня это!!!"
Запишите ЕЕПРОМ программатором и прочитайте её потом контроллером в УАРТ.
Сделайте запись с проверкой и лейте диагностику в УАРТ (или хотя бы мигайте лампочкой).
Или к телепатам.
Запишите ЕЕПРОМ программатором и прочитайте её потом контроллером в УАРТ.
Сделайте запись с проверкой и лейте диагностику в УАРТ (или хотя бы мигайте лампочкой).
Или к телепатам.
Запись с проверкой уже сделал, чтение возвращает 0xff. Записывать EEPROM программатором пока не пробовал.
Цитата(Fenolftalein @ Aug 1 2011, 19:45)
Запись с проверкой уже сделал, чтение возвращает 0xff.
МПЛаб, как я уже писал, при работе с ЕЕПРОМ симулирует всё, кроме напряжения питания и джиттера таймера записи. Поэтому могу предположить только (см. include/eeprom_routines.h):
Код
/* NOTE WELL:
The macro EEPROM_READ() is NOT safe to use immediately after any
write to EEPROM, as it does NOT wait for WR to clear. This is by
design, to allow minimal code size if a sequence of reads is
desired. To guarantee uncorrupted writes, use the function
eeprom_read() or insert
while(WR)continue;
before calling EEPROM_READ().
*/
The macro EEPROM_READ() is NOT safe to use immediately after any
write to EEPROM, as it does NOT wait for WR to clear. This is by
design, to allow minimal code size if a sequence of reads is
desired. To guarantee uncorrupted writes, use the function
eeprom_read() or insert
while(WR)continue;
before calling EEPROM_READ().
*/
Цитата(xemul @ Aug 1 2011, 20:08)
МПЛаб, как я уже писал, при работе с ЕЕПРОМ симулирует всё, кроме напряжения питания и джиттера таймера записи. Поэтому могу предположить только (см. include/eeprom_routines.h):
Код
/* NOTE WELL:
The macro EEPROM_READ() is NOT safe to use immediately after any
write to EEPROM, as it does NOT wait for WR to clear. This is by
design, to allow minimal code size if a sequence of reads is
desired. To guarantee uncorrupted writes, use the function
eeprom_read() or insert
while(WR)continue;
before calling EEPROM_READ().
*/
The macro EEPROM_READ() is NOT safe to use immediately after any
write to EEPROM, as it does NOT wait for WR to clear. This is by
design, to allow minimal code size if a sequence of reads is
desired. To guarantee uncorrupted writes, use the function
eeprom_read() or insert
while(WR)continue;
before calling EEPROM_READ().
*/
Добавил перед чтением ожидание сброса флага WR. Это ничего не меняет, в моей программе чтение происходит гарантированно через промежуток времени, достаточный для записи.
Записать EEPROM программатором не удалось, выдает ошибку при верификации. Есть еще идеи?
Заменить контроллер.
Или если именно этот контроллер Вам дорог и если в ЕЕПРОМ пишется нечасто, использовать вместо неё флэш.
Или если именно этот контроллер Вам дорог и если в ЕЕПРОМ пишется нечасто, использовать вместо неё флэш.
EEPROM используется для запоминания настроек устройства при его отключении. Запись производится каждый раз при отключении питания, поэтому не хочу использовать флэш. Еще идеи? Если у МК есть EEPROM, то он должен писаться, по моему так.
Цитата(Fenolftalein @ Aug 2 2011, 17:33)
Если у МК есть EEPROM, то он должен писаться, по моему так.
Могу предположить, что так оно и задумывалось.
Согласно Вашему описанию проблемы, вариантов кроме каким-то образом прибитой ЕЕПРОМ у меня нет. Потому и предложил заменить контроллер.
UPD: в стародавние времена (2003 г.) была эррата для F627A_628A_648A на предмет записи в ЕЕПРОМ при разрешённом LVP. Посмотрите, может для F876A тоже есть нечто подобное.
Цитата(xemul @ Aug 2 2011, 18:24)
Могу предположить, что так оно и задумывалось.
Согласно Вашему описанию проблемы, вариантов кроме каким-то образом прибитой ЕЕПРОМ у меня нет. Потому и предложил заменить контроллер.
UPD: в стародавние времена (2003 г.) была эррата для F627A_628A_648A на предмет записи в ЕЕПРОМ при разрешённом LVP. Посмотрите, может для F876A тоже есть нечто подобное.
Согласно Вашему описанию проблемы, вариантов кроме каким-то образом прибитой ЕЕПРОМ у меня нет. Потому и предложил заменить контроллер.
UPD: в стародавние времена (2003 г.) была эррата для F627A_628A_648A на предмет записи в ЕЕПРОМ при разрешённом LVP. Посмотрите, может для F876A тоже есть нечто подобное.
В эррате описана только одна ошибка, связанная с EEPROM. Повышенное потребление в ждущем режиме, если EEADDR указывает на значение отличное от 0xFF.
Обнаружил следующую вещь: если прочитать EEPROM после долгого выключения, то чтение вернет 0, но последующие чтения будут возвращать уже 255. Что это? Уже проблема чтения или записи? (В промежутке между чтениями производится запись в EEPROM)
Цитата(Fenolftalein @ Aug 3 2011, 11:48)
Что это? Уже проблема чтения или записи? (В промежутке между чтениями производится запись в EEPROM)
С таким анамнезом попробуйте обратиться к чудотворцам или телепатам.
Согласно Вашему описанию проблемы у меня таки был ещё один вариант - с контроллером и ЕЕПРОМ всё в порядке (я дважды столкнулся с физической неисправностью ЕЕПРОМ в пиках - когда испытывал 16C84 на живучесть, и когда она действительно почему-то сама сдохла; был ещё прикол, когда ни в какую не писался последний байт в определённой последовательности 3-х или 4-х байтов, но это вряд ли Ваш случай), а траблы, соответственно, в других местах, - но я не стал его озвучивать, т.к. вероятность одновременных (не|слабо)кореллированных проблем в разных местах должна быть существенно меньше вероятности одной локальной проблемы, какой бы маловероятной она не была.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.