Миландр

Здравствуйте! У меня есть "пара" вопросов к опытным пользователям микросхемы 1636РР2У, либо к разработчикам. Работаю на оборонку, сам недавно пришел на предприятие и впервые работаю с этой ПЗУ. И после прочтения спецификации вопросов стало еще больше.
Конкретнее работа в параллельном режиме.
Суть:
1. В табл.2 указано что для записи необходимо се=0 we=0 oe=1, но как следует дальше, все таки необходимо произвести стробирование we и ce, и по спаду записывать адреса, а по фронту записывать данные, причем по таблице5 на программирование 4 цикла: 555 АА, 2АА 55, 555 А0, РА РD. Но если смотреть на диаграмму, то я не заметил там идущих подряд этих циклов(рис13, рис14), причем судя по диаграмме, по сути там идет только 555 A0, PA PD. Вопрос: Так как же все таки организовать программирование в параллельном режиме?
2. После завершения последовательности программирования необходимо следить за статусными битами или ждать паузу максимального времени программирования ипроверять данные, а потом только переходить к записи следующего байта в следующую ячейку. Вопрос: А можно не ждать эту паузу(300мкс), а сразу приступать к программированию следующей ячейки без проверки тех данных которые записались в предыдущую ячейку? а то 300 мкс - довольно таки долгая пауза.
3. То же самое что и 2 вопрос, только в байпасе. можно ли программировать друг за другом ячейки не выжидая паузу для проверки правильно ли записан байт, а только после завершения операции программирования всех ячеек прочитать с целью проверки весь массив данных который был записан. А то если заходить в байпас, записывать байт в байпасе, потом выходить из байпаса чтобы перейти в режим чтения - это будет гораздо дольше стандартной операции программирования, и тогда я не вижу смысл байпаса.

Объясните, пожалуйста, начинающему специалисту, как правильно организовать программирование в параллельном режиме и желательно по рабоче-крестьянски

1. Да в таблице истинности для записи правильнее было указывать фронт (передний из нуля в единицу и для записи данных и для записи адреса). Командная последовательность программирования по таблице 5 состоит из 4 циклов записи, на временной диаграмме показаны два последних цикла записи командной последовательности программирования (это разные понятия). Цикл записи на параллельной шине это не тоже самое что последовательность программирования.
2. В новой версии спецификации или руководства по эксплуатации необходимо следить за статусными битами, причём статусные биты гарантируют более информативное отслеживание входа в режим программирования и выхода из него. Ожидание паузы худший вариант, а не проверять биты, не ждать паузу и непрерывно писать нельзя. Следующая операция программирования не начнётся пока не завершена предыдущая.
3. Ответ тот же выжидать паузу не обязательно, но статусные биты проверять обязательно до окончания программирования. Выходить из режима bypass не нужно для чтения данных. Если не выполняется любая внутренняя операция в любом режиме стандартный или bypass ячейки доступны для чтения.

P.S. Все проблемы которые возникают у пользователей на данный момент связаны с тем подходом программирования, который Вы описывали, писать, ничего не ждать, не проверять, а в конце проверить всю матрицу, в результате не записанные ячейки, стирание всей матрицы и заново повторять весь процесс и так до бесконечности. И большинство вопросов сразу снимается после того как Вы начнёте работать с flash и попробуете все её режимы. Читать, писать, только изучив основательно можно принять для себя тот или иной подход, если строгие рекомендации про проверке статусных бит, записанной информации Вам не подходит. Просто читая спецификацию, без практических применений не понять всех особенностей работы.

Здравствуйте! У меня возникли проблемы при записи FLASH в параллельном режиме.
После отправки командной последовательности программирования байта процесс записи не заканчивается, при этом
опрос статусных бит показывает, что бит D6 постоянно переключается, бит D5 не устанавливается в единицу, даже если время программирования
давно вышло и бит D7 никогда не принимает значение, равное записанным данным.

Ниже прикреплена временная диаграмма. На ней время указано в отсчётах, частота отсчётов 40 МГц.

Чтобы правильно считывать статусные бита нельзя держать CE и OE постоянно в нуле а переключать в неактивное состояние, на диаграмме у Вас CE и ОE постоянно в нуле и не видно переключение на D6, а читается всё время 0x40.ещё непонятно зачем после командной последовательности проходит короткий импульс записи по WE. И в начале диаграммы перед командной последовательностью Вы читаете ячейку с адресом 2, что в ней хранилось до этого?

Хорошо. Получается, что для чтения статусных бит необходимо использовать временную диаграмму цикла чтения 2 (рис.12)? А для чего тогда применяется временная диаграмма цикла чтения 1?

В ячейке с адресом 2 хранилось 8'hFF. Я проверяю это до начала записи. Импульс записи по WE -это переход от процедуры записи к процедуре чтения. Тут, наверное, и есть косяк?

Временная диаграмма 1 для чтения данных из памяти, переключающийся бит может переключаться только при чтении по временной диаграмме 2 с изменением CE или OE.
Лишний импульс записи на шине может привести к сбросу командной последовательности, его надо устранить. Ещё может быть установлена защита от записи, тогда запись также не начнётся. Непонятно почему тогда читается всё время 40h на шине данных, если в ячейке 2 значение FF.

Здравствуйте, возникла проблема при работе с флэшкой. Не могу записать данные, переключающийся бит не меняется, постоянно считываю0xFF. Вообще никакой реакции во время процедуры записи не наблюдаю. Хотя процессс считывания ID производителя и устройства проходит нормально. В чем может быть проблема? Спасибо.

Осциллограмма чтения и записи.

Добрый день! Вновь вернулась к программированию микросхемы памяти 1636РР2У. И опять с ней возникают проблемы. Микросхема используется для записи времени наработки изделия. Данные времени - 32-х разрядное число. Данные резервируются в 3 разных сектора. Запись происходит каждые пять минут. Алгоритм такой: каждые пять минут непрерывной работы данные вычитываются из ячеек памяти, сравниваются 3 полученных значения, анализируются. Если все 3 числа совпадают, то данные времени увеличиваются на единицу и перезаписываются все 3 сектора.. Если совпадают данные двух ячеек, то они записываются в качестве нового времени наработки(+1 конечно же)... Если все три числа разные, то записываем сообщение об ошибке. На практике получается следующее: устройство программируется, микросхема инициализируется, данные времени непрерывно контролируются. Запись и чтение происходит без сбоев. Далее начинаем выключать и включать устройство.. И тут как повезёт, либо после включения мы читаем нормальные данные, либо читаем сообщение об ошибке записи. Подскажите, что с этим можно сделать? Дело в том, что ошибка возникает нерегулярно: ни на каких-то определённых значениях, ни в определённый момент времени..

Anna
А зачем так сложно? Можно каждые 5 минут записывать (устанавливать в 0) один бит во флэш. При включении считаем количество установленных в ноль битов, умножаем на пять минут и определяем время наработки в минутах. Можете и резервирование сделать в разных секторах, если есть жгучее желание. При таком подходе один и то же байт в памяти можно перезаписывать несколько раз без предварительного стирания сектора. При интервале в 5 минут этой микросхемы хватит больше, чем на 100 лет.

Да, мне казалось это таким простым и очевидным) Задача изначально стояла научиться записывать/стирать любые данные во флэш) В общем, освоить полностью функционал) Вы мне открыли глаза) Но вопрос остаётся открытым.

По существу проблемы. Если я правильно понял, то раз в пять минут вы стираете три сектора, затем пишете в них новые увеличенные значения наработки изделия. Следовательно, каждые пять минут возникает сравнительно непродолжительный (3* 220 мс = 660 мс = 0,66 с)
интервал времени, требуемый на стирание секторов, в течение которого у вас все результаты испорчены.
Вероятность того, что при выключении изделия вы попадете на такой момент:
p = 0,66 c / (5 * 60 c) = 0,0022 = 0,22%
Вроде и немного, но вполне достаточно, чтобы раз в несколько дней (при частых отключениях) у вас результаты наработки исчезли.
Вывод: нельзя такой подход применять.

Еще можно по очереди писать значение наработки в два сектора, снабжая каждую запись CRC-кодом. При включении питания читаем обе записи.
Если обе записи исправны (CRC совпадает), то выбираем ту, которая больше и берем ее в качестве искомой величины.
Если одна из записей окажется битой (CRC не совпадает), то ее игнорируем, а берем другую.
Если обе записи битые, то, увы, счетчик наработки сбрасываем в ноль.
Каждые пять минут стираем самую старую запись и пишем очередное значение наработки. После записи тут же читаем и проверяем CRC. При несовпадении CRC перезаписываем вновь.
При таком подходе потерять сможем лишь некоторое время наработки, но не всё.
В этом решении мне не нравится то, что один и тот же сектор регулярно подвергается стиранию. Конечно, количество циклов перезаписи декларировано в дадашите, как 100000, но всё равно неприятно.

Спасибо за ответы! Буду переписывать алгоритм.