|
CycloneII и NAND Flash, ошибка при чтении ID |
|
|
|
Aug 4 2009, 06:03
|

Гуру
     
Группа: Свой
Сообщений: 2 113
Регистрация: 1-11-05
Пользователь №: 10 359

|
Всем привет. Итак, на плате с CycloneII имеется NAND Flash (от микрона, хотя это не суть важно, т.к. интерфейс один у всех). Для начала пробую работать с этой памятью с помощью Nios через PIO. Первая же простейшая операция чтения ID явно происходит неверно. 5 байт вместо ID кода получаю 0xfe,0x00,0x00,0x00,0xbc. Выкладываю код подпрограммы чтения ID и картинку, по которой я это делаю. Код void flash_r_id (unsigned char* res) { unsigned int i; IOWR_ALTERA_AVALON_PIO_DIRECTION(PIO_F_DQ_BASE, 1); //данные на выход IOWR_ALTERA_AVALON_PIO_DATA(PIO_F_ALE_BASE,0); //ALE = 0 IOWR_ALTERA_AVALON_PIO_DATA(PIO_F_CE1_N_BASE,0); //CE = 0 IOWR_ALTERA_AVALON_PIO_DATA(PIO_F_CLE_BASE,1); //CLE = 1 IOWR_ALTERA_AVALON_PIO_DATA(PIO_F_WE_N_BASE,0); //WE = 0 IOWR_ALTERA_AVALON_PIO_DATA(PIO_F_RE_N_BASE,1); //RE = 1 IOWR_ALTERA_AVALON_PIO_DATA(PIO_F_DQ_BASE,0x90); // flash_delay();
IOWR_ALTERA_AVALON_PIO_DATA(PIO_F_WE_N_BASE,1); //WE = 1 IOWR_ALTERA_AVALON_PIO_DATA(PIO_F_CLE_BASE,0); //CLE = 0 flash_delay(); IOWR_ALTERA_AVALON_PIO_DATA(PIO_F_ALE_BASE,1); //ALE = 1 flash_delay();
IOWR_ALTERA_AVALON_PIO_DATA(PIO_F_WE_N_BASE,0); //WE = 0 IOWR_ALTERA_AVALON_PIO_DATA(PIO_F_DQ_BASE,0x00); // flash_delay(); IOWR_ALTERA_AVALON_PIO_DATA(PIO_F_WE_N_BASE,1); //WE = 1 flash_delay(); flash_delay(); flash_delay(); flash_delay(); IOWR_ALTERA_AVALON_PIO_DATA(PIO_F_ALE_BASE,0); //ALE = 0 flash_delay(); flash_delay(); flash_delay();
IOWR_ALTERA_AVALON_PIO_DIRECTION(PIO_F_DQ_BASE, 0); //данные на вход for (i = 0; i < 5; i++) { IOWR_ALTERA_AVALON_PIO_DATA(PIO_F_RE_N_BASE,0); //RE = 0 flash_delay(); flash_delay(); *res = IORD_ALTERA_AVALON_PIO_DATA(PIO_F_DQ_BASE); IOWR_ALTERA_AVALON_PIO_DATA(PIO_F_RE_N_BASE,1); //RE = 1 }
IOWR_ALTERA_AVALON_PIO_DATA(PIO_F_CE1_N_BASE,1); //CE = 0
}
void flash_delay() { unsigned char i; for(i = 0; i < 100; i++){}; } Вот, поглядите, может что забыл или вовсе не то делаю?
Эскизы прикрепленных изображений
--------------------
Быть. torizin-liteha@yandex.ru
|
|
|
|
2 страниц
1 2 >
|
 |
Ответов
(1 - 14)
|
Aug 5 2009, 15:05
|
Местный
  
Группа: Участник
Сообщений: 222
Регистрация: 27-01-09
Из: г.Жирновск
Пользователь №: 44 025

|
Цитата(torik @ Aug 5 2009, 13:27)  Вот еще вопрос появился. в каждой странице памяти 2192 байта, их можно использовать все или с адреса 2048 есть какие-то ограничения? Просто не хочу файловую систему организовывать и контроль ошибок, хочу просто использовать дополнительное место для служебных данных... Дело не в файловой системе, "лишние" 144 байта это 36 дополнительных байт на каждую подстраничку из 512 байт. В эти 36 байт пишется номер странички, адрес предыдущей и последующей страничек, контрольные суммы для восстановления. В настоящее время в NAND упор делается как раз на восстановление данных. И Вы, уверен на 100%, поставите в свой проект самый дешевый чип за 400 рублей. А они сделаны как раз по MLC технологии. Основное "достоинство" этой технологии в том, что максимальное число записей не более 10 тысяч, и сыпятся данные в них с максимально возможной скоростью. Если Вы не будете использовать процедуру восстановления данных, полноценно работать с NAND просто не сможете. Данные будут постоянно теряться. Как вариант писать параллельно в несколько мест. Тогда можно не использовать лишние несколько байт в странице. Потому что у Вас контрольная сумма в полный размер данных
--------------------
Еж - птица гордая. Не пнешь - не полетит.
|
|
|
|
|
Aug 6 2009, 04:55
|

Гуру
     
Группа: Свой
Сообщений: 2 113
Регистрация: 1-11-05
Пользователь №: 10 359

|
Цитата И еще по теме, но не по вопросу - при разработке системы на будущее имейте ввиду, что со сременем все растет, а в этих флэшах растет в первую очередь размер страницы. Уже сейчас искать большие чипы с 2К страницей тяжело - делают 4К. Спасибо, учту. Цитата Использовать можно, но помните о возможности возникновения bad-блоков на лету. Лучше использовать это место для индикации занятости/неисправности страницы. Дополнительно можно хранить и другие служебные данные. Цитата Дело не в файловой системе, "лишние" 144 байта это 36 дополнительных байт на каждую подстраничку из 512 байт. В эти 36 байт пишется номер странички, адрес предыдущей и последующей страничек, контрольные суммы для восстановления. В настоящее время в NAND упор делается как раз на восстановление данных. И Вы, уверен на 100%, поставите в свой проект самый дешевый чип за 400 рублей. А они сделаны как раз по MLC технологии. Основное "достоинство" этой технологии в том, что максимальное число записей не более 10 тысяч, и сыпятся данные в них с максимально возможной скоростью. Если Вы не будете использовать процедуру восстановления данных, полноценно работать с NAND просто не сможете. Данные будут постоянно теряться. Как вариант писать параллельно в несколько мест. Тогда можно не использовать лишние несколько байт в странице. Потому что у Вас контрольная сумма в полный размер данныхsmile.gif Собственно, в качестве служебных данных я и хотел использовать данные о том, занята страница или нет, битый ли блок (насколько я понимаю, битый блок не означает, что его нельзы использовать?). Место под CRC обязательно оставлю на будущее.
--------------------
Быть. torizin-liteha@yandex.ru
|
|
|
|
|
Aug 7 2009, 11:21
|

Гуру
     
Группа: Свой
Сообщений: 2 113
Регистрация: 1-11-05
Пользователь №: 10 359

|
Цитата Все производители пишут, что битый блок не следует использовать целиком, а не только битые страницы. Мы в своей аппаратуре делам следующим образом. Если блок уже битый - не используем, если был целый, но не смогли записать страницу (образовался битый на лету), то уже записанные страницы оставляем, а неисправную пишем повторно в следующий свободный. После очередного стирания/форматирования весь блок помечается как битый и не используется в дальнейшем. А нет ли какого-нибудь алгоритма, обзорной статьи, описания работы контроллера NAND Flash? С интерфейсом-то разобрался, пока интерфейс реализую программно в Nios непосредственно через PIO. Програмно - для отработки ПО и алгоритмов всвязи с нехваткой времени, позже заменю на "железный контроллер". Но пока незнаю на что опереться, где подглядеть реализацию как самого контроллера в железе, так и алгоритм хранения данных (в сомой же флешке и хранить данные о битых блоках (у меня нет больше ПЗУ? Или каждый раз при включении проверять блоки на занятость/исправность?)...
--------------------
Быть. torizin-liteha@yandex.ru
|
|
|
|
|
Aug 12 2009, 07:19
|

Гуру
     
Группа: Свой
Сообщений: 2 113
Регистрация: 1-11-05
Пользователь №: 10 359

|
Ну так чё, кто подскажет алгоритм работы?
Мне в памяти надо хранить кадры изображения (5 блоков каждый) и, наверное, доп. информацию о битых блоках и прочее.
Сперва форматируем память, в процессе чего определяем какие блоки неисправны, получаем таблицу из 4096 байт, каждый из которых говорит о состоянии конкретного блока. Теперь хотелось бы записать эти данные на флеш, чтобы при последующем включении прочитать их. Модификация таблицы и запись будет происходить, по идее, каждый раз, когда появляется битый блок (как минимум), а может и после записи каждого кадра. Получается, что писать в один блок нельзя, надо несколько блоков под это дело выделить и писать поочередно (увеличить ресурс памяти).
Вообще как-то все запутано, может есть рекомендации/алгоритм или статься по FAT для Flash? Самое главное - как обеспечить надежную запись служебной таблицы всвязи с довольно частой ее перезаписью?
--------------------
Быть. torizin-liteha@yandex.ru
|
|
|
|
|
Aug 12 2009, 13:42
|
Группа: Участник
Сообщений: 6
Регистрация: 6-04-07
Из: Россия
Пользователь №: 26 821

|
Можно покопаться в исходниках файловой системы YAFFS (http://ru.wikipedia.org/wiki/YAFFS/ http://www.yaffs.net/), если есть много свободного времени.  В двух словах, надо разделить физический блок памяти (страницу NAND например) и логический. В таком случае вся реализация контроля целостности, равномерности распределения перезаписей и т.п. будет реализовываться при работе с физическим блоком. Вот тут как раз и используются те самые дополнительные байты в каждой странице NAND. Таким образом получается, что при работе с логическими блоками Вы уже не думаете о всех заморочках NAND, а просто используете "идеальные" блоки памяти, на которые можно хоть FAT положить. Но в Вашем случае можно вместо FAT и по проще самопальную "файловую систему" использовать. Цитата(torik @ Aug 12 2009, 11:19)  Самое главное - как обеспечить надежную запись служебной таблицы всвязи с довольно частой ее перезаписью? При указанном подходе отпадает надобность в такой таблице. Для каждого физического блока все служебные данных хранятся в его же дополнительных байтах. Если интересует, могу коротко рассказать суть. Когда то разрабатывал подобную FS (еще до появления YAFFS, вернее параллельно с ней по времени). Единственно, что к FPGA это не имеет никакого отношения, чистое программирование.
|
|
|
|
|
Aug 12 2009, 22:57
|
Гуру
     
Группа: Свой
Сообщений: 2 106
Регистрация: 23-10-04
Из: С-Петербург
Пользователь №: 965

|
Если запись подряд, то можете слизать алгоритм с меня. Реализовано на циклоне третьем. Перед записью в блок производится считывание служебной области нулевой страницы блока и проверяется нулевой байт, если он 0xFF, то блок целый, можно писать. Затем пишутся страницы в блок и переход к следующему блоку. Если произошла ошибка записи, то проверяется следующий блок и, если он не плохой, то страница пишется повторно в него, в страницу с тем же номером относительно начала блока. Если блок плохой - пропускаем его и повторяем со следующим. При стирании или форматировании обнаруживаются недописанные блоки и помечаются как плохие. Это, конечно, по уставу не положено, но вполне работает, поскольку делается однократно. Здесь, конечно, нет никакой файловой системы, записи идут подряд, и стереть можно или все, или хвост.
|
|
|
|
|
Aug 13 2009, 00:40
|

Участник

Группа: Свой
Сообщений: 62
Регистрация: 2-04-09
Из: Москва
Пользователь №: 47 059

|
Цитата(awa @ Aug 12 2009, 17:42)  Единственно, что к FPGA это не имеет никакого отношения, чистое программирование. Сорри, если вставлю свою пять копеек. Если нет "чрезвычайной" необходимости реализовывать "железную" FS для FLASH, лучше этого не делать. Даже для RT и прочих критических систем для этих целе есть OS. Через пару лет переписывать придется все заново. Цитата(torik @ Aug 12 2009, 11:19)  Ну так чё, кто подскажет алгоритм работы?
Мне в памяти надо хранить кадры изображения (5 блоков каждый) и, наверное, доп. информацию о битых блоках и прочее.
Сперва форматируем память, в процессе чего определяем какие блоки неисправны, получаем таблицу из 4096 байт, каждый из которых говорит о состоянии конкретного блока. Теперь хотелось бы записать эти данные на флеш, чтобы при последующем включении прочитать их. Модификация таблицы и запись будет происходить, по идее, каждый раз, когда появляется битый блок (как минимум), а может и после записи каждого кадра. Получается, что писать в один блок нельзя, надо несколько блоков под это дело выделить и писать поочередно (увеличить ресурс памяти).
Вообще как-то все запутано, может есть рекомендации/алгоритм или статься по FAT для Flash? Самое главное - как обеспечить надежную запись служебной таблицы всвязи с довольно частой ее перезаписью? Если чем-то поможет могу привести ссылку http://www.ibm.com/developerworks/linux/li...sh-filesystems/В свое время с этим делом заморачивался (но как драйвер для Linux), если вспомню интересные ссылки, могу привести. Цитата(torik @ Aug 12 2009, 11:19)  Ну так чё, кто подскажет алгоритм работы? Самое главное - как обеспечить надежную запись служебной таблицы всвязи с довольно частой ее перезаписью? А вот это уже точно "чистое программирование". Очень мощные алгоритмы есть, но они опять же не для FPGA.
Сообщение отредактировал zverek - Aug 13 2009, 00:44
|
|
|
|
|
Aug 13 2009, 04:53
|

Гуру
     
Группа: Свой
Сообщений: 2 113
Регистрация: 1-11-05
Пользователь №: 10 359

|
Цитата Можно покопаться в исходниках файловой системы YAFFS (http://ru.wikipedia.org/wiki/YAFFS/ http://www.yaffs.net/), если есть много свободного времени. wink.gif В двух словах, надо разделить физический блок памяти (страницу NAND например) и логический. В таком случае вся реализация контроля целостности, равномерности распределения перезаписей и т.п. будет реализовываться при работе с физическим блоком. Вот тут как раз и используются те самые дополнительные байты в каждой странице NAND. Таким образом получается, что при работе с логическими блоками Вы уже не думаете о всех заморочках NAND, а просто используете "идеальные" блоки памяти, на которые можно хоть FAT положить. Но в Вашем случае можно вместо FAT и по проще самопальную "файловую систему" использовать. Цитата(torik @ Aug 12 2009, 11:19) * Самое главное - как обеспечить надежную запись служебной таблицы всвязи с довольно частой ее перезаписью? При указанном подходе отпадает надобность в такой таблице. Для каждого физического блока все служебные данных хранятся в его же дополнительных байтах. Если интересует, могу коротко рассказать суть. Когда то разрабатывал подобную FS (еще до появления YAFFS, вернее параллельно с ней по времени). Если бы чуть подробнее, было бы просто здорово! Цитата Единственно, что к FPGA это не имеет никакого отношения, чистое программирование. Повторюсь, я работаю с помощью nios-процессора, т.е. чистое програмирование. Мне важен именно алгоритм. Цитата Для каждого физического блока все служебные данных хранятся в его же дополнительных байтах. В том числе и о неисправности блока? Это первое. Второе: кадр занимает 5 блоков. Если какой-то блок в процессе работы становится неисправным, кадр будет расположен не в блоках заподряд, а будет использовать свободные исправные. В этом случае первый блок не сможет содержать информацию о следующем, т.к. записан раньше. Два этих случая наводят меня на мысль о необходимости таблицы со служебной информацией. Вот и давайте обсудим. Цитата Если чем-то поможет могу привести ссылку http://www.ibm.com/developerworks/linux/li...sh-filesystems/В свое время с этим делом заморачивался (но как драйвер для Linux), если вспомню интересные ссылки, могу привести. Спасибо, читал статейку, есть даже перевод на русском. Цитата При стирании или форматировании обнаруживаются недописанные блоки и помечаются как плохие. Над этим вопросом я тоже задумывался. Предположим, блок дал сбой при записи или стирании. Необходимо считать его плохим и... пометить как вы говорите. Как пометить его, если он плохой и не подлежит записи? Только в служебную таблицу...
--------------------
Быть. torizin-liteha@yandex.ru
|
|
|
|
|
Aug 13 2009, 08:50
|
Гуру
     
Группа: Свой
Сообщений: 2 106
Регистрация: 23-10-04
Из: С-Петербург
Пользователь №: 965

|
Цитата Над этим вопросом я тоже задумывался. Предположим, блок дал сбой при записи или стирании. Необходимо считать его плохим и... пометить как вы говорите. Как пометить его, если он плохой и не подлежит записи? Только в служебную таблицу... Я уже отмечал, что это не очень честно, но работает. На практике битые блоки всегда позволяют записать хотя бы несколько нулевых битов в каждый байт. Этим и пользуемся. Маркер исправности - все 1. По поводу разбиений блоков данных - у меня нет адреса следующего блока в предыдущем. Адрес следующего блока всегда +1 от предыдущего или плюс сколько-то, если появились bad'ы. Они отслеживаются при чтении по наличию неиспользованных страниц. Это, глобально, не лучший способ, но поскольку нужно все было реализовывать в реальном времени и еще довольно жестком, то пришлось делать на автоматах и поэкономить на алгоритме.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|