Для тех, кому лень читать: карты SanDisk High Endurance используют флэш-память SanDisk/Toshiba 3D TLC. На то, чтобы установить это, у меня ушло гораздо больше времени, чем должно было (и всё из-за SanDisk!).
Ранее я рассматривал microSD карточки от SanDisk, предназначенные для использования в приложениях, требующих интенсивной записи данных, вроде видеорегистраторов. Тогда я изучил результаты тестов на скорость и поразмышлял о том, какого типа NAND Flash используется в карте. SanDisk не публикует детальных описаний внутренностей карт, поэтому мне ничего не оставалось, как самому заняться реверс-инжинирингом карточки.
Надеясь нарыть информации, я отправил емейл в поддержку SanDisk с вопросом о том, NAND Flash какого типа они используют в своей линейке High Endurance, а также о метриках на выносливость – таких, как количество циклов P/E (Program/Erase), и общего количества записанных терабайт (TBW). К сожалению, сотрудник поддержки SanDisk не смог дать удовлетворительных ответов на мои вопросы, поскольку они не дают информации, не указанной в опубликованных спецификациях. Мне сообщили, что во всех их карточках используется MLC Flash, что можно считать верным, если называть TLC Flash 3-bit «MLC» (как делает Samsung).
Дам им медальку с надписью «вы пытались».
Может показаться, что карточка microSD представляет собой монолитное устройство. Однако такие карточки состоят из множества разных чипов, каждый из которых исполняет свою роль. У простейшей SD-карты будет контроллер, управляющий чипами NAND Flash, и общающийся с хостом (ПК, камерой, и т.п.), а также с самой NAND Flash (состоящей из одного или нескольких флэш-кристаллов). В блоге Bunnie Studios есть прекрасная статья о конструкции SD-карт, включая описание подделок и их изготовления.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/f42/128/888/f42128888111e48aec02f3628775a242.png)
Блок-схема типичной SD-карты
В microSD карточках часто (но не всегда) встречаются испытательные площадки, использующиеся для программирования и испытаний NAND Flash на производстве. Их можно использовать для восстановления данных, или повторного использования microSD карт с дефектным контроллером или прошивкой. Они позволяют превратить карточку в простую NAND Flash – об этом можно почитать в блоге Гауа Луи. Отметим, что стандарта на такие тестовые площадки не существует (даже в рамках одного производителя), однако у некоторых производителей, в частности, SanDisk, существуют закономерности, облегчающие реверс-инжиниринг.
Карты microSD попадают в категорию «монолитных» флэш-устройств, поскольку комбинируют контроллер и NAND Flash в единый неразборный корпус. Многие производители выводят шину данных флэш на скрытые (и практически не имеющие документации) тестовые площадки. С их помощью другие производители карт памяти и USB-флэшек делают недорогие накопители из отказавших запчастей. Контроллер можно просто отключить, и использовать флэш как обычный чип.
В случае карт от SanDisk информация по распиновке их тестовых площадок крайне скудна. В каждом поколении есть свои отличия, но схема расположения остаётся по большому счёту без изменений. Отличия могут быть фатальными, так как контакты для питания и земли иногда меняются местами (а при неправильной полярности чип ждёт мгновенная смерть!).
У моей карточки (а также у многих карт компании из дорогой линейки – не Ultra) тестовые площадки покрыты не лаком, а какой-то эпоксидкой, изготовленной при помощи трафаретной печати, с вырезанным лазером серийным номером. Я погрел, поскрёб, и сумел удалить это очень хрупкое покрытие с тестовых площадок. При этом я удалил и серийный номер – вероятно, эта нечто вроде гарантийной печати.
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/b76/8e9/040/b768e9040fe1db41336987895c994b8a.jpg)
Эпоксидное покрытие тестовых площадок
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/fd9/8c2/fcf/fd98c2fcfc03efdd3b33f2efeff41f55.jpg)
Тестовые площадки на виду
Удалив следы эпоксидного покрытия, я встретился со знакомым расположением тестовых площадок, к которым снизу прибавились несколько дополнительных.
Концепция интерфейсного модуля довольно проста. Для каждой из тестовых площадок выводим провод, ведущий к площадке большего размера, для облегчения доступа, и подключаем нормальную SD-шину к SD-коннектору, чтобы контроллер делал свою работу, пока мы возимся с шиной NAND Flash. Учитывая малый размер тестовых площадок и большое их число, результат может получиться немного неаккуратным.
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/9d0/0eb/3ea/9d00eb3ea22cd2bf3ebbfdcecbf12b3b.jpg)
Интерфейсный модуль в сборе
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/56e/ca3/e03/56eca3e03f14c1b232e9595b415a28c3.jpg)
Интерфейсный модуль, увеличенное фото
Я начал с того, что прикрепил карту двусторонним скотчем к макетной плате. Потом я залудил все площадки и припаял небольшой керамический конденсатор на 1 мкФ на площадки питания Vcc и земли GND карты. Используя эмалированный провод толщиной 40 AWG (0,1 мм), я соединил каждую тестовую площадку с соответствующим контактом на макетной плате. Вместе с дополнительными площадками это составило 28 крохотных проводочков!
Для коннектора SD я использовал кабель с устройством для обслуживания телефонов под Android от HTC "XTC 2 Clip". Оно работало как «гибкая удалённая SD-карта» и разводило сигналы по небольшому гибкому кабелю. Я замотал кабель медной плёнкой для защиты от шума и усиления, и припаял плёнку к внешним площадкам макетной платы для упрочнения конструкции. Потом я залудил конец кабеля, и подсоединил эмалированные провода к контактам карточки. Затем я врезал в провод питания светодиод с резистором, чтобы было видно, когда карта получает питание.
Разведя все тестовые площадки по тестовым контактам, я мог начать разбираться в том, за что отвечают эти контакты в плане доступа к NAND Flash, находящейся внутри карты.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/9f2/fd2/0c5/9f2fd20c552ef0b7c2338f71ce88ec67.png)
В целом расположение контактов совпадало с большинством microSD карточек от SanDisk.
Для анализа сигналов со всех контактов я использовал логический анализатор DSLogic Plus. Распиновка для передачи данных уже была известна, и самая тяжёлая работа уже была проделана (шина данных, управление, адреса, команды, защита записи, статус занято/свободно). Однако роль не каждого из контактов была очевидной сразу – найденная мною распиновка включала в себе минимальное количество шин, позволявших работать с NAND Flash – за исключением управляющей шины, переводящей контроллер в режим сброса, и отключающей его от управления шинами данных (позже это будет важным).
Прослушивая шину данных на максимальной доступной для DSLogic скорости (и используя имеющийся буфер на 32 МБ), я смог составить чёткий список команд, отправляемых на NAND Flash с контроллера в момент инициализации.
Я, в частности, искал две команды: RESET (0xFF) и READ ID (0x90). В поисках последовательностей команд важно знать, когда и как меняются шины данных и управления. Постараюсь объяснить всё по шагам. Если вам интересно, рекомендую инструкцию от Micron, где описываются основы работы NAND Flash и даётся куда как больше информации о принципах её работы.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/f64/4a8/ad5/f644a8ad5191c24e85c9da67744e5def.png)
Отслеживание команды RESET у SanDisk High Endurance 128 ГБ при помощи логического анализатора. Пунктиром отмечено появление команд записи и сброса.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/a0e/dd9/f0b/a0edd9f0b1630051878ca7cac6f7b063.png)
Отслеживание команды RESET у SanDisk High Endurance 128 ГБ при помощи логического анализатора. Пунктиром отмечено появление команд чтения/записи.
Когда команда RESET отправляется на NAND Flash, сначала вниз подтягивается шина /CE (Chip Select, Active Low). Затем вверх подтягивается шина CLE (Command Latch Enable); шина данных устанавливается в своё запланированное значение 0xFF (в двоичном коде); затем шина /WE (Write Enable, Active Low) переходит от высокого к низкому напряжению, а потом возвращается к высокому (данные с шины данных передаются на чип, когда шина /WE переходит от низкого напряжения к высокому, т.н. «фронт сигнала»); шина CLE притягивается обратно вниз, возвращаясь в нормальное состояние. Затем чип флэш-памяти притягивает шину R/B (Ready/Busy Status) вниз, чтобы показать, что он занят сбросом, а по окончанию возвращает шину обратно на верхний уровень.
Команда READ ID работает сходным образом, за исключением того, что после записи команды 0x90 (1001 0000) в шину данных, он притягивает вверх шину ALE (Address Latch Enable), а не CLE, и записывает 0x00 (все двоичные нули), приводя /WE в нижнее состояние. Чип передаёт записанный в него NAND Flash ID во внутренний регистр чтения, и данные читаются с устройства на каждом фронте шины /RE (Read Enable, Active Low); для большинства устройств это от 4 до 8 байт данных.
У каждого устройства NAND Flash есть свой (по большей части) уникальный идентификатор, относящий его к конкретному производителю и другие функциональные данные, определённые производителем. Иначе говоря, хорошо определён только ID производителя, назначаемый технологической ассоциацией JEDEC.
Первый байт обозначает производителя чипа, а остальные (от 2 до 6) определяют характеристики устройства – все они определяются самим производителем. Большинство производителей NAND очень неохотно публикуют технические характеристики устройств, и SanDisk (и, соответственно, Toshiba/Kioxia) очень строго контролируют эти данные, за исключением утекших в интернет немного устаревших технических описаний устройств от Toshiba. Поскольку у упомянутых компаний общие производственные мощности, можно сделать обоснованное предположение, что структуры данных в определяемых производителями данных можно сопоставлять друг с другом.
Что до карты SanDisk High Endurance 128 ГБ, она использует NAND Flash ID of 0x45 48 9A B3 7E 72 0D 0E. Некоторые из этих цифр можно сравнить со спецификацией от Toshiba:
Хотя не все байтовые значения можно определить однозначно, мне удалось определить, что карточки SanDisk High Endurance используют BiCS3 3D TLC NAND Flash – по крайней мере, это 3D NAND, значительно превышающая по надёжности традиционные плоские NAND. К сожалению, только на основе этой информации нельзя сказать, пользуется ли контроллер какими-либо преимуществами механизма SLC кэширования в операциях записи.
Геометрия производственного процесса чипа определяется исходя из четырёх первых байтов Flash ID и их сопоставления со строчкой конфигурационного файла инструментов от Silicon Motion для контроллера SM3271 USB Flash и контроллера SM2258XT DRAM-less SSD. Эти инструменты выдают предполагаемые артикулы от чипов SDTNAIAMA-256G и SDUNBIEMM-32G соответственно, но мне кажется, что это не соответствует конфигурации флэш-памяти в этой карточке.
Я хотел убедиться, что получаю правильный ID с NAND Flash, поэтому я подключил плату для отладки Texas Instruments MSP430FR2433 и написал простейший код, отправляющий нужные команды RESET и READ ID, и пытающийся параллельно извлечь дополнительные данные из скрытых параметров чипа JEDEC Parameter Page.
Первым препятствием у меня на пути стало то, что MSP430 сбрасывался каждый раз при попытке отправить команду RESET, что говорило о том, что ограниченная мощность питания платы MSP430 не справляется с таким током. Это может происходить при "конкуренции за шину", когда два устройства дерутся друг с другом, пытаясь одновременно подать на определённую цифровую шину высокое и низкое напряжение. Я не был уверен в том, что понимаю, что происходит, поскольку в свободном доступе информации о том, как отключить встроенный контроллер карты, не было (а он из-за этого «отпускает» шину NAND и позволяет другому устройству взять над ней контроль).
Я разобрался, что тестовая площадка А1 (см. схему) – это шина сброса контроллера, и если удерживать её напряжение в нижнем положении, контроллер полностью освобождает контроль над шиной NAND Flash. После этого мой код с микроконтроллера смог прочесть Flash ID правильно и без помех.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/025/ac9/e5b/025ac9e5bcfd2ceb88f8e9a88c291ab0.png)
Чтение Flash ID с карты
При наличии на странице параметров JEDEC содержатся подробные характеристики Flash-чипа – куда как более подробные по сравнению с NAND Flash ID – и, к тому же, более стандартизированные. Оказалось, однако, что SanDisk решила проигнорировать стандарт и использовать собственный! Обычно страница начинается с ASCII-строчки «JEDEC», однако я обнаружил повторяющуюся строку «SNDK» (обозначение компании на бирже) и другие данные, не соответствовавшие ничему из спецификации JEDEC! Ну, попробовать стоило.
Я собрал данные при помощи того же скетча для Arduino, что привёл ранее, и получил 1536 байт данных. На Ideone я написал небольшую программку, чтобы преобразовать первые 512 байт в аккуратный HEX-дамп:
Дальнейший анализ при помощи анализатора DSLogic показал, что контроллеру требуется страница параметров размером 4128 б (4 кб + 32 б), заполненная всё теми же повторяющимися данными, что приведены выше.
Изучая данные с логического анализатора, я обнаружил, что контроллер отправляет команду READ ID дважды, но в первый раз без сброса Flash (что обычно нужно делать сразу после подачи питания на чип!). Возвращаемые при этом чипом данные оказываются, мягко говоря, странными.
Сначала это сбило меня с толку, ведь я пытался получить идентификатор, анализируя только логику. Но поговорив с человеком, имеющим большой опыт в восстановлении данных с NAND Flash, я узнал, что для устройств от SanDisk это норма. Они очень вольно относятся к специальным командам и структурам данных. Если верить четвёртому байту, то размер блока составляет 4 МБ, что для современного Flash-чипа выглядит правдоподобно. Остальная информация не имеет для меня смысла, кроме того, что первый байт говорит о том, что производителем чипа была Toshiba.
Я зашёл слишком далеко в своих попытках получить ответ на простой вопрос о том, какие именно чипы SanDisk использовала в своей карте, предназначенной для продолжительной работы. Казалось бы, они могли с гордостью рассказывать о том, что используют для повышенной надёжности и долгосрочной работы технологию 3D NAND – но нет!
Для интересующихся выкладываю данные, перехваченные мною с карты после её включения. Также выкладываю грубый скетч для Arduino, позволяющий вручную считывать NAND ID и страницу параметров:
Ранее я рассматривал microSD карточки от SanDisk, предназначенные для использования в приложениях, требующих интенсивной записи данных, вроде видеорегистраторов. Тогда я изучил результаты тестов на скорость и поразмышлял о том, какого типа NAND Flash используется в карте. SanDisk не публикует детальных описаний внутренностей карт, поэтому мне ничего не оставалось, как самому заняться реверс-инжинирингом карточки.
Техническая поддержка, которая не справилась
Надеясь нарыть информации, я отправил емейл в поддержку SanDisk с вопросом о том, NAND Flash какого типа они используют в своей линейке High Endurance, а также о метриках на выносливость – таких, как количество циклов P/E (Program/Erase), и общего количества записанных терабайт (TBW). К сожалению, сотрудник поддержки SanDisk не смог дать удовлетворительных ответов на мои вопросы, поскольку они не дают информации, не указанной в опубликованных спецификациях. Мне сообщили, что во всех их карточках используется MLC Flash, что можно считать верным, если называть TLC Flash 3-bit «MLC» (как делает Samsung).
Дорогой Джейсон,
Спасибо за обращение в поддержку пользователей SanDisk Global. Мы признательны вам за то, что вы принадлежите к нашей семье SanDisk.
Как я понял, вы хотите побольше узнать о нашей карточке SanDisk High Endurance для видео мониторинга. Позвольте сообщить вам, что все наши карты памяти используют флэш-технологию Multi level cell. Однако количество циклов чтения/записи флэш-памяти не публикуется и не документируется. Публикуется только скорость чтения и записи, а именно 100 МБ/с и 40 МБ/с. Карточка на 64 ГБ может записывать видео Full HD до 10 000 часов. Подробности можно узнать по ссылке.
SANDISK HIGH ENDURANCE VIDEO MONITORING microSD CARD
С уважением,…
Дам им медальку с надписью «вы пытались».
Анатомия SD-карты
Может показаться, что карточка microSD представляет собой монолитное устройство. Однако такие карточки состоят из множества разных чипов, каждый из которых исполняет свою роль. У простейшей SD-карты будет контроллер, управляющий чипами NAND Flash, и общающийся с хостом (ПК, камерой, и т.п.), а также с самой NAND Flash (состоящей из одного или нескольких флэш-кристаллов). В блоге Bunnie Studios есть прекрасная статья о конструкции SD-карт, включая описание подделок и их изготовления.
![](https://habrastorage.org/getpro/habr/post_images/f42/128/888/f42128888111e48aec02f3628775a242.png)
Блок-схема типичной SD-карты
В microSD карточках часто (но не всегда) встречаются испытательные площадки, использующиеся для программирования и испытаний NAND Flash на производстве. Их можно использовать для восстановления данных, или повторного использования microSD карт с дефектным контроллером или прошивкой. Они позволяют превратить карточку в простую NAND Flash – об этом можно почитать в блоге Гауа Луи. Отметим, что стандарта на такие тестовые площадки не существует (даже в рамках одного производителя), однако у некоторых производителей, в частности, SanDisk, существуют закономерности, облегчающие реверс-инжиниринг.
Крадущийся контроллер, затаившиеся тестовые площадки
Карты microSD попадают в категорию «монолитных» флэш-устройств, поскольку комбинируют контроллер и NAND Flash в единый неразборный корпус. Многие производители выводят шину данных флэш на скрытые (и практически не имеющие документации) тестовые площадки. С их помощью другие производители карт памяти и USB-флэшек делают недорогие накопители из отказавших запчастей. Контроллер можно просто отключить, и использовать флэш как обычный чип.
В случае карт от SanDisk информация по распиновке их тестовых площадок крайне скудна. В каждом поколении есть свои отличия, но схема расположения остаётся по большому счёту без изменений. Отличия могут быть фатальными, так как контакты для питания и земли иногда меняются местами (а при неправильной полярности чип ждёт мгновенная смерть!).
У моей карточки (а также у многих карт компании из дорогой линейки – не Ultra) тестовые площадки покрыты не лаком, а какой-то эпоксидкой, изготовленной при помощи трафаретной печати, с вырезанным лазером серийным номером. Я погрел, поскрёб, и сумел удалить это очень хрупкое покрытие с тестовых площадок. При этом я удалил и серийный номер – вероятно, эта нечто вроде гарантийной печати.
![](https://habrastorage.org/getpro/habr/post_images/b76/8e9/040/b768e9040fe1db41336987895c994b8a.jpg)
Эпоксидное покрытие тестовых площадок
![](https://habrastorage.org/getpro/habr/post_images/fd9/8c2/fcf/fd98c2fcfc03efdd3b33f2efeff41f55.jpg)
Тестовые площадки на виду
Удалив следы эпоксидного покрытия, я встретился со знакомым расположением тестовых площадок, к которым снизу прибавились несколько дополнительных.
Создание интерфейсного модуля
Концепция интерфейсного модуля довольно проста. Для каждой из тестовых площадок выводим провод, ведущий к площадке большего размера, для облегчения доступа, и подключаем нормальную SD-шину к SD-коннектору, чтобы контроллер делал свою работу, пока мы возимся с шиной NAND Flash. Учитывая малый размер тестовых площадок и большое их число, результат может получиться немного неаккуратным.
![](https://habrastorage.org/getpro/habr/post_images/9d0/0eb/3ea/9d00eb3ea22cd2bf3ebbfdcecbf12b3b.jpg)
Интерфейсный модуль в сборе
![](https://habrastorage.org/getpro/habr/post_images/56e/ca3/e03/56eca3e03f14c1b232e9595b415a28c3.jpg)
Интерфейсный модуль, увеличенное фото
Я начал с того, что прикрепил карту двусторонним скотчем к макетной плате. Потом я залудил все площадки и припаял небольшой керамический конденсатор на 1 мкФ на площадки питания Vcc и земли GND карты. Используя эмалированный провод толщиной 40 AWG (0,1 мм), я соединил каждую тестовую площадку с соответствующим контактом на макетной плате. Вместе с дополнительными площадками это составило 28 крохотных проводочков!
Для коннектора SD я использовал кабель с устройством для обслуживания телефонов под Android от HTC "XTC 2 Clip". Оно работало как «гибкая удалённая SD-карта» и разводило сигналы по небольшому гибкому кабелю. Я замотал кабель медной плёнкой для защиты от шума и усиления, и припаял плёнку к внешним площадкам макетной платы для упрочнения конструкции. Потом я залудил конец кабеля, и подсоединил эмалированные провода к контактам карточки. Затем я врезал в провод питания светодиод с резистором, чтобы было видно, когда карта получает питание.
Анализ шины
Разведя все тестовые площадки по тестовым контактам, я мог начать разбираться в том, за что отвечают эти контакты в плане доступа к NAND Flash, находящейся внутри карты.
![](https://habrastorage.org/getpro/habr/post_images/9f2/fd2/0c5/9f2fd20c552ef0b7c2338f71ce88ec67.png)
В целом расположение контактов совпадало с большинством microSD карточек от SanDisk.
Для анализа сигналов со всех контактов я использовал логический анализатор DSLogic Plus. Распиновка для передачи данных уже была известна, и самая тяжёлая работа уже была проделана (шина данных, управление, адреса, команды, защита записи, статус занято/свободно). Однако роль не каждого из контактов была очевидной сразу – найденная мною распиновка включала в себе минимальное количество шин, позволявших работать с NAND Flash – за исключением управляющей шины, переводящей контроллер в режим сброса, и отключающей его от управления шинами данных (позже это будет важным).
Прослушивая шину данных на максимальной доступной для DSLogic скорости (и используя имеющийся буфер на 32 МБ), я смог составить чёткий список команд, отправляемых на NAND Flash с контроллера в момент инициализации.
Основы прослушивания шины и NAND I/O (запись команд, адресов, чтение данных)
Я, в частности, искал две команды: RESET (0xFF) и READ ID (0x90). В поисках последовательностей команд важно знать, когда и как меняются шины данных и управления. Постараюсь объяснить всё по шагам. Если вам интересно, рекомендую инструкцию от Micron, где описываются основы работы NAND Flash и даётся куда как больше информации о принципах её работы.
![](https://habrastorage.org/getpro/habr/post_images/f64/4a8/ad5/f644a8ad5191c24e85c9da67744e5def.png)
Отслеживание команды RESET у SanDisk High Endurance 128 ГБ при помощи логического анализатора. Пунктиром отмечено появление команд записи и сброса.
![](https://habrastorage.org/getpro/habr/post_images/a0e/dd9/f0b/a0edd9f0b1630051878ca7cac6f7b063.png)
Отслеживание команды RESET у SanDisk High Endurance 128 ГБ при помощи логического анализатора. Пунктиром отмечено появление команд чтения/записи.
Когда команда RESET отправляется на NAND Flash, сначала вниз подтягивается шина /CE (Chip Select, Active Low). Затем вверх подтягивается шина CLE (Command Latch Enable); шина данных устанавливается в своё запланированное значение 0xFF (в двоичном коде); затем шина /WE (Write Enable, Active Low) переходит от высокого к низкому напряжению, а потом возвращается к высокому (данные с шины данных передаются на чип, когда шина /WE переходит от низкого напряжения к высокому, т.н. «фронт сигнала»); шина CLE притягивается обратно вниз, возвращаясь в нормальное состояние. Затем чип флэш-памяти притягивает шину R/B (Ready/Busy Status) вниз, чтобы показать, что он занят сбросом, а по окончанию возвращает шину обратно на верхний уровень.
Команда READ ID работает сходным образом, за исключением того, что после записи команды 0x90 (1001 0000) в шину данных, он притягивает вверх шину ALE (Address Latch Enable), а не CLE, и записывает 0x00 (все двоичные нули), приводя /WE в нижнее состояние. Чип передаёт записанный в него NAND Flash ID во внутренний регистр чтения, и данные читаются с устройства на каждом фронте шины /RE (Read Enable, Active Low); для большинства устройств это от 4 до 8 байт данных.
NAND Flash ID
У каждого устройства NAND Flash есть свой (по большей части) уникальный идентификатор, относящий его к конкретному производителю и другие функциональные данные, определённые производителем. Иначе говоря, хорошо определён только ID производителя, назначаемый технологической ассоциацией JEDEC.
Первый байт обозначает производителя чипа, а остальные (от 2 до 6) определяют характеристики устройства – все они определяются самим производителем. Большинство производителей NAND очень неохотно публикуют технические характеристики устройств, и SanDisk (и, соответственно, Toshiba/Kioxia) очень строго контролируют эти данные, за исключением утекших в интернет немного устаревших технических описаний устройств от Toshiba. Поскольку у упомянутых компаний общие производственные мощности, можно сделать обоснованное предположение, что структуры данных в определяемых производителями данных можно сопоставлять друг с другом.
Что до карты SanDisk High Endurance 128 ГБ, она использует NAND Flash ID of 0x45 48 9A B3 7E 72 0D 0E. Некоторые из этих цифр можно сравнить со спецификацией от Toshiba:
Байт (16-ричный) | Описание |
---|---|
45 |
Производитель: SanDisk |
48 |
I/O напряжение: Вероятно 1.8 volts (померял мультиметром) Ёмкость: вероятно 128 ГБ (нет данных в спецификации) |
9A |
Тип NAND: TLC (Triple-Level Cell / 3 бита на ячейку) Кристаллов памяти на /CE: 4 (карта использует 4 чипа по 32 ГБ) |
B3 |
Размер блока: 12 Мб (768 страниц на блок) за исключением запасной площади Размер страницы: 16 384 байт / 16 кб за исключением запасной площади |
7E |
Матриц на /CE: 8 (2 матрицы на кристалл) |
72 |
Интерфейс: асинхронный Геометрия процесса: BiCS3 3D NAND |
0D |
Неизвестно (в спецификации нет информации) |
0E |
Неизвестно (в спецификации нет информации) |
Хотя не все байтовые значения можно определить однозначно, мне удалось определить, что карточки SanDisk High Endurance используют BiCS3 3D TLC NAND Flash – по крайней мере, это 3D NAND, значительно превышающая по надёжности традиционные плоские NAND. К сожалению, только на основе этой информации нельзя сказать, пользуется ли контроллер какими-либо преимуществами механизма SLC кэширования в операциях записи.
Геометрия производственного процесса чипа определяется исходя из четырёх первых байтов Flash ID и их сопоставления со строчкой конфигурационного файла инструментов от Silicon Motion для контроллера SM3271 USB Flash и контроллера SM2258XT DRAM-less SSD. Эти инструменты выдают предполагаемые артикулы от чипов SDTNAIAMA-256G и SDUNBIEMM-32G соответственно, но мне кажется, что это не соответствует конфигурации флэш-памяти в этой карточке.
Внешнее управление
Я хотел убедиться, что получаю правильный ID с NAND Flash, поэтому я подключил плату для отладки Texas Instruments MSP430FR2433 и написал простейший код, отправляющий нужные команды RESET и READ ID, и пытающийся параллельно извлечь дополнительные данные из скрытых параметров чипа JEDEC Parameter Page.
Первым препятствием у меня на пути стало то, что MSP430 сбрасывался каждый раз при попытке отправить команду RESET, что говорило о том, что ограниченная мощность питания платы MSP430 не справляется с таким током. Это может происходить при "конкуренции за шину", когда два устройства дерутся друг с другом, пытаясь одновременно подать на определённую цифровую шину высокое и низкое напряжение. Я не был уверен в том, что понимаю, что происходит, поскольку в свободном доступе информации о том, как отключить встроенный контроллер карты, не было (а он из-за этого «отпускает» шину NAND и позволяет другому устройству взять над ней контроль).
Я разобрался, что тестовая площадка А1 (см. схему) – это шина сброса контроллера, и если удерживать её напряжение в нижнем положении, контроллер полностью освобождает контроль над шиной NAND Flash. После этого мой код с микроконтроллера смог прочесть Flash ID правильно и без помех.
![](https://habrastorage.org/getpro/habr/post_images/025/ac9/e5b/025ac9e5bcfd2ceb88f8e9a88c291ab0.png)
Чтение Flash ID с карты
Страница параметров JEDEC… или, по крайней мере, то, что с ней сделала SanDisk!
При наличии на странице параметров JEDEC содержатся подробные характеристики Flash-чипа – куда как более подробные по сравнению с NAND Flash ID – и, к тому же, более стандартизированные. Оказалось, однако, что SanDisk решила проигнорировать стандарт и использовать собственный! Обычно страница начинается с ASCII-строчки «JEDEC», однако я обнаружил повторяющуюся строку «SNDK» (обозначение компании на бирже) и другие данные, не соответствовавшие ничему из спецификации JEDEC! Ну, попробовать стоило.
Я собрал данные при помощи того же скетча для Arduino, что привёл ранее, и получил 1536 байт данных. На Ideone я написал небольшую программку, чтобы преобразовать первые 512 байт в аккуратный HEX-дамп:
Offset 00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F 0123456789ABCDEF
------ --+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-- ----------------
0x0000 53 4E 44 4B 53 4E 44 4B 53 4E 44 4B 53 4E 44 4B SNDKSNDKSNDKSNDK
0x0010 53 4E 44 4B 53 4E 44 4B 53 4E 44 4B 53 4E 44 4B SNDKSNDKSNDKSNDK
0x0020 08 08 00 08 06 20 00 02 01 48 9A B3 00 05 08 41 ..... ...H.....A
0x0030 48 63 6A 08 08 00 08 06 20 00 02 01 48 9A B3 00 Hcj..... ...H...
0x0040 05 08 41 48 63 6A 08 08 00 08 06 20 00 02 01 48 ..AHcj..... ...H
0x0050 9A B3 00 05 08 41 48 63 6A 08 08 00 08 06 20 00 .....AHcj..... .
0x0060 02 01 48 9A B3 00 05 08 41 48 63 6A 08 08 00 08 ..H.....AHcj....
0x0070 06 20 00 02 01 48 9A B3 00 05 08 41 48 63 6A 08 . ...H.....AHcj.
0x0080 08 00 08 06 20 00 02 01 48 9A B3 00 05 08 41 48 .... ...H.....AH
0x0090 63 6A 08 08 00 08 06 20 00 02 01 48 9A B3 00 05 cj..... ...H....
0x00A0 08 41 48 63 6A 08 08 00 08 06 20 00 02 01 48 9A .AHcj..... ...H.
0x00B0 B3 00 05 08 41 48 63 6A 08 08 00 08 06 20 00 02 ....AHcj..... ..
0x00C0 01 48 9A B3 00 05 08 41 48 63 6A 08 08 00 08 06 .H.....AHcj.....
0x00D0 20 00 02 01 48 9A B3 00 05 08 41 48 63 6A 08 08 ...H.....AHcj..
0x00E0 00 08 06 20 00 02 01 48 9A B3 00 05 08 41 48 63 ... ...H.....AHc
0x00F0 6A 08 08 00 08 06 20 00 02 01 48 9A B3 00 05 08 j..... ...H.....
0x0100 41 48 63 6A 08 08 00 08 06 20 00 02 01 48 9A B3 AHcj..... ...H..
0x0110 00 05 08 41 48 63 6A 08 08 00 08 06 20 00 02 01 ...AHcj..... ...
0x0120 48 9A B3 00 05 08 41 48 63 6A 08 08 00 08 06 20 H.....AHcj.....
0x0130 00 02 01 48 9A B3 00 05 08 41 48 63 6A 08 08 00 ...H.....AHcj...
0x0140 08 06 20 00 02 01 48 9A B3 00 05 08 41 48 63 6A .. ...H.....AHcj
0x0150 08 08 00 08 06 20 00 02 01 48 9A B3 00 05 08 41 ..... ...H.....A
0x0160 48 63 6A 08 08 00 08 06 20 00 02 01 48 9A B3 00 Hcj..... ...H...
0x0170 05 08 41 48 63 6A 08 08 00 08 06 20 00 02 01 48 ..AHcj..... ...H
0x0180 9A B3 00 05 08 41 48 63 6A 08 08 00 08 06 20 00 .....AHcj..... .
0x0190 02 01 48 9A B3 00 05 08 41 48 63 6A 08 08 00 08 ..H.....AHcj....
0x01A0 06 20 00 02 01 48 9A B3 00 05 08 41 48 63 6A 08 . ...H.....AHcj.
0x01B0 08 00 08 06 20 00 02 01 48 9A B3 00 05 08 41 48 .... ...H.....AH
0x01C0 63 6A 08 08 00 08 06 20 00 02 01 48 9A B3 00 05 cj..... ...H....
0x01D0 08 41 48 63 6A 08 08 00 08 06 20 00 02 01 48 9A .AHcj..... ...H.
0x01E0 B3 00 05 08 41 48 63 6A 08 08 00 08 06 20 00 02 ....AHcj..... ..
0x01F0 01 48 9A B3 00 05 08 41 48 63 6A 08 08 00 08 06 .H.....AHcj.....
Дальнейший анализ при помощи анализатора DSLogic показал, что контроллеру требуется страница параметров размером 4128 б (4 кб + 32 б), заполненная всё теми же повторяющимися данными, что приведены выше.
Проблемы сброса
Изучая данные с логического анализатора, я обнаружил, что контроллер отправляет команду READ ID дважды, но в первый раз без сброса Flash (что обычно нужно делать сразу после подачи питания на чип!). Возвращаемые при этом чипом данные оказываются, мягко говоря, странными.
Байт (16-ричный) | Описание |
---|---|
98 |
Производитель: Toshiba |
00 |
I/O напряжение: неизвестно (нет данных) Ёмкость устройства: неизвестно (нет данных) |
90 |
Тип NAND: SLC (Одноуровневая ячейка / 1 бит на ячейку) Кристаллов Flash на /CE: 1 |
93 |
Размер блока: 4 МБ, за исключением запасной площади Размер страницы: 16 384 байт / 16 кб, за исключением запасной площади |
76 |
Матриц на /CE: 2 |
72 |
Тип интерфейса: асинхронный Геометрия процесса: 70 нм плоский |
Сначала это сбило меня с толку, ведь я пытался получить идентификатор, анализируя только логику. Но поговорив с человеком, имеющим большой опыт в восстановлении данных с NAND Flash, я узнал, что для устройств от SanDisk это норма. Они очень вольно относятся к специальным командам и структурам данных. Если верить четвёртому байту, то размер блока составляет 4 МБ, что для современного Flash-чипа выглядит правдоподобно. Остальная информация не имеет для меня смысла, кроме того, что первый байт говорит о том, что производителем чипа была Toshiba.
Заключение
Я зашёл слишком далеко в своих попытках получить ответ на простой вопрос о том, какие именно чипы SanDisk использовала в своей карте, предназначенной для продолжительной работы. Казалось бы, они могли с гордостью рассказывать о том, что используют для повышенной надёжности и долгосрочной работы технологию 3D NAND – но нет!
Файлы
Для интересующихся выкладываю данные, перехваченные мною с карты после её включения. Также выкладываю грубый скетч для Arduino, позволяющий вручную считывать NAND ID и страницу параметров: