Jump to content

    

antsava

Участник
  • Content Count

    11
  • Joined

  • Last visited

Community Reputation

0 Обычный

Контакты

  • Сайт
    Array
  • ICQ
    Array
  1. угу, спасибо, да, ошибок в MX целом немного (за исключением отдельных серий, старых ревизий (mx575..795)), ошибка по переполнению uart при приеме не очень приятна, но думаю это можно обойти посредством DMA (During a RX FIFO overflow condition, the shift register stops receiving data. This causes the UART to lose synchronization with the serial data stream. The only way to recover from this is to turn the UART OFF and ON until it synchronizes. This could require several OFF/ON sequences.) и кое-где встречается ошибка CPU при записи в регистры периферии и срабатывании перрывания (During normal operation, if a CPU write operation to a peripheral is interrupted by an incoming interrupt, it should be aborted (not completed) and resumed after the interrupt is serviced. However, some of these write operations may not be aborted, resulting in a double write to peripherals by the CPU (the first write during the interrupt and the second write after the interrupt is serviced), но, в принципе, это все решаемые моменты.
  2. Спасибо, возьмем на заметку) Может действительно остановимся на mx5xx, mx450/350... приглянулись тем, что вроде еррата меньше, чем в остальных семействах (за исключением озвученного бага). На крайняк, для наших задач кристаллы pin-to-pin получаются (mx4 - mx5).
  3. Всем привет, стоит вопрос о постановке pic32mx в устройство. Смотрю errata на PIC32MX330/350/370/430/450/470 (http://ww1.microchip.com/downloads/en/DeviceDoc/80000574F.pdf). Смущает item#12: The Open Drain selection (ODCx) on I/O port pins is not available when the pin is configured for anything other than a standard port output. In addition, the Open Drain feature is not available for dedicated or remappable Peripheral Pin Select (PPS) output features. Правильно ли я понимаю, что на работу пинов I2C это не влияет? (пины которые жестко закреплены за I2C, напр. pins 31,32 SDA2/SCL2) Т.е. ограничений на работу I2C нет? (т.е. блок I2C "сам" управляет этими пинами, и описанные ограничения на него не распространяются). Касаемо пинов PPS (кроме тех, что жестко за I2C закреплены), как я понял - в них нельзя использовать режим Open Drain согласно описанной проблеме. Если кто поднимал I2C на семействе mx350/370/450/470, нет ли там серьезных проблем по этому блоку? Заранее спасибо всем, кто ответит.
  4. Рекомендую посмотреть стандарт на память, ONFI какой-то там (в даташите на микросхему указано какому стандарту она соответствует). В стандарте все прописано + пример на псевдокоде, привожу какой-то свой старый скриншот из onfi 2.2. Вкратце, для новой микросхемы с завода помечают - на самой первой странице каждого блока (хотя в стандарте написано, что может быть и последняя страница), 1й байт(слово) в дополнительной области (spare area). Если он равен 0, а не FF это заводской битый блок
  5. Стояла "задача" убедится, что это не мы где-то накосячили... перепроверяли возможные варианты... Закончилось, точнее в процессе заканчивания - да, делаем ECC (microblaze, в дальнейшем fpga), она с лихвой исправляет имеющиеся ошибки. Спасибо за совет по повод термопрогона,(надо будет отнести в климат.камеру, интересно будет потом посмотреть больше ошибок станет или нет). Да, у нас бывают косяки с пайкой, возможно действительно перегрели микросхемы... Спасибо! думаю пригодятся.
  6. Возвращаюсь к данной теме... вспоминаем понемного... Тест: стираем, пишем нули. Несколько раз считываем уже записанные данные. ( стираем nand, проверяем что после стирания == 0xFFFF, всегда норм, нет ошибок ) Типы ошибок: -- есть ошибки которые при каждом чтении остаются на своих местах, (их большинство) -- есть ошибки, которые при повторных чтениях - то есть, то нет (их меньше) если перезалить плису и прочесть ранее записанные нули, ошибки остаются на тех же местах, - повторное стирание и запись этого же блока -- есть ошибки которые остаются на тех же местах, что и при прошлой записи -- есть ошибки, которые возникают на новых местах скриншот прилагается. To be continue...
  7. давно не писал, переключался на другие задачи. Проверил софтовую часть общения с nand (на уровне команд nand) на другой плате. там стоял SLC чип от micron MT29F2G08(ABD) + ARM. Те же тесты, 8 битых "заводских" блоков, битовых ошибок нет вообще(!) (запись-чтение нулей, отладочных счетчиков...) без всяких ECC. Т.о. софтовая ошибка отпадает...
  8. угу, придется) спасибо. Да, напряжения питания и уровни сигналов проверяли, в норме, 1.8 В как и должно быть, фронты не завалены. Остаются времянки и помехи... доступ к nand - через самописный контроллер nand-памяти (писал другой разработчик, я реализую софт под microblaze). Поначалу прочли ID, параметры, записали-прошли маленький буфер, все совпало и успокоились. Времянки на 1й взгляд тоже нормальные были (но теперь понимаю надо детальнее посмотреть). Потом начал писать по несколько страниц, и как раз вылезли битовые ошибки...
  9. Ошибки во времянках "чтения" исключаю. Read Parameter Page, Read Uniq ID, чтение более 5000 раз подряд не выдало ни одной ошибки (т.е. всегда считывается одно и то же). -- Интересно, если например в Features писать-читать кучу раз для проверки правильности обращения к nand при записи, наверное ж там ничего не испортится/не затрется? (писать естественно адекватные значения, чтоб не сбоить работу nand). Пробовал запись-чтение нулей в timing_mode 0...5 (выставление в features в nand), результаты примерно одинаковые. Доп.задержки в софте при выполнении команд, использование read status enhanced вместо read statusnдля отдельного LUN-а чтоб всякие конфликты исключить, успехов не дало. "Мучить" софтовую библиотеку пока перестаю. на выходных попробую ее на МК запустить, нашел платку с nand, hardware_level правда другой будет, но хотя бы убежусь что с командами нормально работаю. Собираю статистику по каждому типу ошибок (сколько остаются на своих местах при повторных стираниях-записях, сколько остаются при повторных чтениях...). Ну и буду внимательнее времянки смотреть...
  10. Спасибо за ответы! Есть пища для размышлений... Как будут новые результаты / прояснится ситуация отпишусь.
  11. Всем привет. Столкнулся со следующей проблемой. Тест nand: стираю блок, записываю несколько страниц нулями, читаю (запись/чтение без использования ECC). Имею ошибки, т.е. не все биты равны 0. Частота ошибок - порядка 8...20 на 64 страницы по 8192 байт. Не особо часто, но и не редко... Насколько я понимаю, для NAND характерны битовые ошибки, они появляются в процессе юзания NAND, для их устранения применяется ECC. -- Меня смущает достаточно большая частота их проявления в новой микросхеме. Так и должно быть? В datasheet-е не нашел информации какой должна быть вероятность (BER, Bit Error Rate), в статьях в интернете натыкался на цифры 10^(-8)... 10^(-11), т.е. значительно реже, чем я наблюдаю (2 * 10^(-6) и выше). В тесте работаю с корректными блоками ( 1. не помеченные как битые с завода, 2. проверка после стирания показывает, что все байты равны 0xFF), проверял тест на нескольких блоках. Повторные чтения уже записанных данных, показывают что ошибки остаются на своих местах, т.е. в тех же страницах, по тем же смещениям в пределах страницы, ошибка в том же бите. В разных ошибочных байтах ошибки могут быть в разных битах. Если еще раз стереть блок и заново обнулить страницы, то часть ошибок остается (те же страницы, те же смещения в пределах страницы...), часть пропадает/появляется в новых местах. чтение ID, страницы параметров - верно читается. память Micron mt29f512g08, MLC