Может не в тот форум попал, но более подходящего не нашел, т.ч. не обессудьте.

Вопрос следующий: вот есть параллельная флешка AT49BV162AT от Atmel, микросхема хорошая, всем требованиям удовлетворяет, кроме одного нефатального, но досадного момента. Программирование флеши (как и стирание и другие режимы) реализуется путем подачи специальной цепочки адресов/данных (адрес 0х555, данные 0хаа, адрес 0хааа, данные 0х55 и т.д.) - это обычное дело для таких дивайсов. Время программирования ячейки (16-бит слова) типовое - 12 мкс, максимальное 200 мкс. Т.е. для гарантированной зашивки, если по времени, то надо ждать эти самые 200 мкс. Для оптимизации этого момента микросхема имеет режим поллинга, т.е. можно после посылки данных на программирование делать чтение и по определенным битам результата чтения определять, запрограммировалось ли слово или нет.

И вот тут то и затаилась засада: выяснилось, что несмотря на поллинг некоторые данные пишутся с ошибками. Причем получается как бы порциями - блок из нескольких подряд данных пишется нормально, затем блок выпадает, затем опять нормально. Если сделать выход из режима программирования не по результату поллинга, а по времени, то все пишется, как часы, т.е. флешь сама нормальная.

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

Если кто сталкивался с подобным и победил (или не победил ), поделитесь опытом?

Т.е. получается, что процедура поллинга "сносит башню" процессу записи? А если пин READY/BUSY Output использовать?

А что про поллинг в datasheet написано? Он ведь может двояко работать - показывать, что алгоритм программирования выполнен, или что программуруемые биты начали опознаваться как 0. Во втором случае надо еще ждать некоторое время для гарантированного программирования. Можно, кончено, и экспериментально подобрать это время, но ядумаю, что если спецмально ничего не сказано, то алгроитм заканчивает работу через 200 мкс, и быстрее не предусмотрено. Остальное рекламный трюк.

Нет, вряд ли, скорее всего просто поллинг выдает готовность и проц выдает команду (последовательность) на завершение процедуры записи. И вот это уже может обламывать оный процесс.


Он у меня не задействован (ног свободных нет), да и к чему он, если и так есть соотвествующая программная процедура. Ради интереса, конечно, можно повозиться, но неохота (другой работы полно). В табличке они все там вместе, т.ч. нет оснований полагать, что тут должно быть в корне по-другому. В общем, мне в текущем проекте скорость особая не нужна, но хотелось прояснить эту ситуацию. На будущее (не люблю оставлять "за спиной" мутные, темные моменты).

Про это конкретно сказано:

The AT49BV162A(T)/163A(T) features Data Polling to indicate the end of a program cycle. ... Once the program cycle has been completed, true data is valid on all outputs and the next cycle may begin. ...

Т.е. конкретно сказано, что означает конец программирования. Другое, имхо, и не нужно - бесполезно оно. Пользователя интересует, когда можно начинать писать следующее слово, а не когда начало "проявляться" текущее.


Да не похоже на рекламу - зачем оно им? А поллинг - нормальный способ определить конец программирования. Еще помню, когда году в 1998-м лепили самодельный программатор для AVR, там тоже использовали поллинг. Штатное время программирования было 4 мс, а с поллингом реально при 5 В получалось около 2.2 мс (это были старые чипы AT908515/2313/m103). Т.е. все работало. Что-то сомнительно, чтобы эта микруха работала неправильно - Атмел давно такие штуки делает, собаку уже съел. Что-то, боюсь, я недопонял, что-то не так сделал. А вот что, не пойму, вроде просто все.

Ну да, трактовка однозначная. А если пользоваться поллингом, а потом таки подождать 200 мкс. Т.е. убедиться, что самим процессом поллинга не сбивается программирование ?
А глюки у ATMEL быают сплошь и рядом. Я вот полтора года назад обнаружил, что если в ATMEGE не запретить в обработчике преывание по пустому регистру данных в UART, то он повторно его не вызывает (как должен по описанию), а прерывания от компаратора и АЦП перестают работать. Начал с техподдержкой переписываться. Так они сначала не верили, а как только убедились - исчезли сразу же, даже спасибо не сказали. Специально проверил в новой ATMEGe(05 года) - нет этого глюка, исправили.

А после записи, перед началом поллинга ждете некоторое время (те самые 12 мкс)? Возможно, что внутренняя логика микросхемы не успевает сработать, и в первом же цикле программа вылетает из ожидания.

Да, это пробовал - собственно, с этого и начал эксперименты. Т.е. когда увидел проблемы, то просто после цикла поллинга добавил задержку. Все стало программироваться нормально.

Да нет, это явно лишнее. В доке непосредственно сказано:

Data Polling may begin at any time during the program cycle.

Т.е. начал цикл программирования и тут же можно начинать поллить. А 12 мкс - это типовое время программирования ячейки. По идее, если бы поллинг работал, то на программирование уходило бы это время. А так для гарантии надо использовать максимальное. Можно, конечно, использовать трюки - типа, запрограммировал ячейку, подождал 12 мкс, вышел из режима, проверил тут же. Если не запрограммировалось, то повторить процесс. Но это, имхо, изврат. Документированные возможности должны работать.

Ну значит либо ошибка в доке, либо в алгоритме поллинга - он кстати готовность не сразу ли показывает ?
Или все-таки какое - то время от команды записи проходит ? Если последнее, значит режим поллинга, скорее всего не работает именно в мсх.

Провел эксперименты. Время программирования, если все нормально, действительно составляет порядка 12 мкс. Делал так: после посылки программирующей последовательности устанавливаю два внешних выводы в 1, после успешного поллинга один сбрасываю, после неуспешного (там есть спец условия) - другой. Обнаружил, что иногда первый вывод устанавливается и через короткое время (несколько сот наносекунд) сбрасывается. Т.е. как будто получает подтверждение от поллинга, что он успешншо завершен. Ессно, это неправильно. Поставил задержку между посылкой программирующей последовательности и началом поллинга и все стало работать правильно. Величину задержки сначала поставил порядка 1 мкс. Поэкспериментировал, выяснил, что при 60 нс задежки еще уверенно не работает, а уже при 100 нс уверенно работает.

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