Эти адреса считываются без проблем на обеих картах. А вот начальные по 00 почему-то. Я не верю, что обе карты оказались уж какими-то "оригинальными"
Значит, есть какой-то нюанс с этими картами. У меня есть карта на 256 Мб и она работает нормально.
Ну и еще раз переспрошу, почему прошивка дробит файл tap на несколько? Заголовок - это один файл, данные - это другой файл в понятии устройства. И между собой эти куски не связаны. Причем после воспроизведения заголовка зависает намертво.
Прошивка ничего не дробит. Но если с карты идёт мусор, она сходит с ума.
почему у всех, кто собирал результат нормальный, а у меня две карты глючат?
Разное бывает.
Опять же не верю, что это из-за того, что я заменил диоды на микросхему 4050.
Что это за микросхема? Насколько она быстрая? CD4050BE? Она?
Но две мои карты на 32 и 256 МБ с этим устройством не работают.
Вот если бы понять, почему, тогда можно было бы учесть особенности таких карт. Вот только в чём тут причина? Карта точно получает команду на чтение и отрабатывает её. Но после передачи сигнала готовности она начинает слать нули. Почему нули? Вот в чём вопрос.
Вот, кстати, подобная проблема. "Ответ 0xFE приходит, о считывает только 0x00."
Я не могу добиться ни ка каких примерах нормальную работу CMD17 чтение блока
даю запрос CMD17,0,0xFF -> 0x00 (вроде как гуд)
жду 0хFE и дожидаюсь
начинаю читать страничку - фигу, тока 0x00 идет и все.
Там пишут, что "После каждой команды нужно,
уже при неактивном CS карты, еще послать минимум 8 клоков." Честно говоря, впервые вижу. Можно попробовать, конечно, но это как бы странно.
Как автор решил проблему и в чём она заключалась там, увы, не написано.\
И вот такая же тоже проблема.
Когда я запускаю cmd17 с адресом (0x00000000) для моей карты из PIC-18F4520 на шине SPI, я получаю правильный токен R1 возврата из командной строки. Затем, после проверки нескольких циклов, я получаю маркер 0xFE, возвращаемый из моего выдающегося SPI_Put_Char (0xFF). Затем должны начаться данные, чтобы я прочитал 512 байт в мой массив IO_Buffer.
Когда я сканирую результаты, я получил много байтов 0x00. Как ни странно, и часто, примерно в позиции 448 в секторе 0, появляются некоторые данные - несколько байтов тут и там - тогда последние 32 байта (я могу видеть только 32 на моем ЖК-экране одновременно) - все нули, за которыми следует маркер 0x55AA ожидается в конце загрузочного сектора.
google translator
В ответах указано вот что:
Наконец-то нашел решение этой проблемы!
Оказывается, вы читали MBR, который находится по адресу 0 на SD-карте. Чтобы найти местоположение загрузочного сектора, нужно прочитать соответствующую запись в MBR. Записи начинаются с адреса 0x01be и по 16 байт каждая. Интересующий элемент в записи находится по смещению 0x08, имеет длину 4 байта и называется LBA. [Википедия] Чтобы получить адрес местоположения загрузочного сектора, нужно умножить LBA на размер сектора (512 байт). [Форум по микрочипам]
Я так понимаю, что там действительно нули и WinHex этот блок как раз не показывает почему-то. Он ноль отсчитывает иначе, если я правильно понял. То есть, сектора начинаются по смещениям в 0x01be+0x08 и умножить на 512. Попробую завтра поэкспериментировать.
Вот в чём дело: