roman555

Проверял той программой, которую вы советовали. Прогнал несколько раз, все нормально. В цикле она работать не умеет. Что значить "сбросить кэш"? Пишутся несколько типов записей 128, 256 и 512 байт. Каждый тип пишется в свою область, области выровнены по границе блока. Естественно, запись НЕ происходит в один сектор, ее адрес постоянно инкрементируется. Области кольцевые, но глюк случается, когда закольцовка еще не произошла. Пропадание данных происходит строго в тот момент, когда карта зависает. Пока склоняюсь к мысли, что карта не совсем корректно работает в spi режиме. Других мыслей пока нет. Карты других вендоров работают нормально.

Который включается 59-й командой? Да, включен. Насчет аппаратной проблемы я думал, но фронты нормальные, питание в норме, да и карты других вендоров работают нормально... В последнем эксперименте я оставил на шине только sd карту. Проблема осталась... Подтяжки есть.

jcxz, под "паразитным" тактированием я имел в виду клоки при обращении к другим устройствам на шине, когда cs карты поднят. aaarrr, да, выполняется. Вы не сталкивались на практике с произвольным пропаданием данных?

jcxz, у меня буфер в ОЗУ размером с запись, т.е 256 байт. Вы, по сути, предлагаете писать страницей, под которую нужно постоянно держать буфер в ОЗУ, которого у меня в обрез. Но это уже детали реализации, которые сейчас не существенны, мне бы проблему пропадания данных решить... Кстати, у меня sd карта сидит на spi, к которому подключено еще 2 устройства, cs у карты, разумеется, свой. Может ли "паразитное" тактирование карты(при поднятом cs) при обращении к другим устройствам на шине приводить к нарушениям в логике работы карты(зависаниям, пропаданиям данных)? Кто нибудь сталкивался?

iosifk, аппаратно все вроде нормально. Частота и так достаточно низкая. Устройство где используются эти карты не новое, проблема именно с этой партией. _4afc_, что значит делать паузы? В документации я ничего не нашел по этому поводу. Каждую отдельную операцию чтения/записи я и так делаю внутри своего цикла CS. Данные пишу с cmd24, читаю c помощью cmd17. Никаких проблем не было, пока не поставили эти карты mirex. Самое неприятное, что пропадают уже записанные данные, зависания не так критичны. В новой партии мы, конечно, будет ставить другие карты, а в старом тираже хотелось бы решить проблему программно, по крайней мере временно. jcxz, а как записывать внутри блока, если адресация блочная? Вот и приходится читаю блок, модицифировать данные и писать его снова.

Спасибо, попробую. Только непонятно в каком режиме эта прога пишет: одиночными секторами или мультиблоком, боюсь это будет не совсем корректный тест. Я думал может кто - то сталкивался с подобным поведением и подскажет в чем может быть дело..

Пишу в raw, размер сектора 512. Когда пишу порциями по 256б, то сначала читаю сектор, модифицирую данные и снова записываю.

Возникла проблема с sd картой Mirex 2Gb в spi режиме. Суть в следующем: карта нормально работает на запись в течении неск. часов, потом в какой то момент вообще перестает подавать признаки жизни (держит busy). Делаю reset по питанию, считываю данные. Вижу, что часть ранее записанных данных пропала, причем пропала не полностью, а кусками примерно по 64к, т.е часть данных есть, потом "дырка", потом снова идут данные. Т.o проблемы две - зависание карты и пропадание данных. В первую очерень хотелось бы разобраться с пропаданием данных. Данные пишу раз в секунду порциями по 256 байт. Просадок по питанию во время работы нет, неиспользуемые линии через 10к подтянуты к +3.3В. Частота spi = 12,5МГц. P.S. C картами других производителей такой проблемы не наблюдается. Дело в том, что часть устройств уже выпущена с этой картой, поменять ее можно, но это долго и затратно, поэтому хотелось бы найти программный способ решения проблемы. P.S.S. Какого размера внутренние буферы записи у карты? Т.е интересует сколько данных может теоретически потеряться при внезапном пропадании питания. Кто что может посоветовать?

Добрый день. Требуется стереть содержимое карты. Пользуюсь связкой команд CMD32+CMD33+CMD38. В качестве начального и конечного адреса указываю 0 и конечный адрес соответственно. Так вот, например, карта Kingston 2 Gb стирается нормально(время стирания 2-3сек), а карта Qumo 2Gb не стираются ни в какую, причем сигнал BUSY после команды CMD38 пропадает через несколько мс(не может карта так быстро стираться). Никаких ошибок карта не возвращает... Кто-нибудь может пояснить почему некоторые карты не стираются? Вроде бы команды стирания по стандарту должны поддерживаться всеми картами. Или реализация алгоритма стирания отдана на откуп конкретного производителя?

После получения Response Token я посылаю dummy байт и, насколько я помню, сразу после этого карта отпускает Busy. После посылки холостого байта я опускаю CS и посылаю еще один dummy байт.

Я так и делаю! Проблема в том, что начиная с третьего блока карта после передачи Response Token держит Busy очень короткое время, поэтому я не успеваю поднять CS. И именно после этого начинаются проблемы. Похоже эта особенность поведения данной карты является непреодолимой и придется всю запись переделать с использованием одиночных блоков.

Благодарю за ответы, думаю на этом тема исчерпана. Кстати, заметил один нюанс: data response перестает приходить, если CS поднимается при сброшенном Busy. Т.е, заканчивается передача данных, приходит response token, я вижу, что Busy падает в "0", а пока я готовлюсь поднять CS, Busy уже успевает перейти в "1" и, спустя некоторое время, CS поднимается в "1". И именно после этого пропадают data response. Насколько критично поднимать CS при сброшенном Busy?

Почему же? Это же обычная практика для spi устройств использовать одну шину и раздельные CS.

Не забыл, dummy байт передается. У меня такое ощущение, что карта игнорирует CS и ловит байты, которые предназначаются другим устройствам на шине. Может ли быть такое, если карта неправильно проинициализировалась, например не перешла в "spi mode"(насколько я знаю в "sd mode", который у карты по умолчанию, CS для работы не требуется)?

Немного изменил алгоритм записи на карту. Теперь чтение очередного блока из внешней RAM я делаю до проверки сигнала занятости карты. Так вот, ситуация изменилась, стало еще интереснее. Теперь корректные Data Response я получаю в ответ на посылки первых двух блоков. В качестве Data Response на посылки остальных блоков я получаю 0xff, после чего вижу, что карта как ни в чем не бывало выставляет Busy. Такое ощущение, что карте не нравится, когда ее тактируют при снятом сигнале Busy. Видимо чтение из внешней RAM для 3-го и последующих блоков происходит когда карта уже освободилась(после посылки первого блока карта выставляет Busy на ~12мс, после передачи остальных блоков Busy снимается гораздо быстрей, через ~2мс).. Кто-нибудь что-нибудь может сказать по этому поводу?

aaarrr, благодарю Вас за советы. Ситуация проясняется. Busy я определяю как наличие 0xff на DAT0. Рассматриваю процесс записи на осциллографе и вижу, что через ~12 мс после передачи первого блока на DAT0 я действительно вижу 0xff. То есть по моему мнению Busy карта сняла. Далее я отпускаю CS карты и считываю данные следующего для записи блока данных из внешней RAM, которая тоже сидит на том же spi. Далее я снова опускаю CS карты и передаю второй блок, после которого Data Response я уже не получаю. Так вот, если я убираю обращение к внешней RAM - запись на карту восстанавливается, на передачу всех блоков я начинаю получать корректный response. Сижу ломаю голову, каким образом чтение из внешней RAM влияет на запись в SD. Единственное, что приходит в голову - карта во время чтения из RAM решает чем - то заняться и опускает Busy(карта продолжает тактироваться клоками во время чтения из RAM), о чем я, естественно, не догадываюсь, т.к проверял Busy раньше и уверен, что карта свободна.

Прошу прощения за неточность описания. Сейчас поясню. Поведение Busy вообще загадка. Как я уже писал, после посылки первого блока Busy держится около 12мс. После отпускания Busy посылается второй блок данных, при этом линия D0 после начала передачи держится в "1" один клок, после чего падает в "0", т.е вместо Data Response Token я читаю 0x00. Однако через уже примерно 2мс карта отпускает D0, т.е снимает Busy и если дальше передавать блоки, то все последующие Data Response Token будут уже равны 0xff. Через некоторое время после такой записи карта начинает в ответ на любую команду возвращать 0x01. P.S. Токен при мультиблочной записи шлю верный - 0xFC.

Что я вижу. После посылки первого блока данных я получаю в ответ корректный Data Token, после чего карта держит "Busy" в течении примерно 12мс. После того, как карта отпустила "Busy", я посылаю второй блок данных, после чего карта Busy уже не отпускает. Да, CS на время Busy я снимаю, т.к на spi у меня живут еще несколько устройств.

Спасибо за ответ. Но у меня проблема с записью. При мультиблочном чтении я так же как и Вы дожидаюсь приема 0xfe. Хотя мультиблочное чтение именно на этой карте я еще не проверял... Попробовал несколько карт других производителей - на первый взгляд таких проблем нет. А с картой Silicon Power такой затык. И именно их мы закупили... Кстати, после того, как карта зависает в ответ, например, на команду 0x55 она начинает слать 0x01 - типа "я нахожусь в idle state". Встречал посты товарища aaarrr, кажется он уже собаку съел на sd картах. aaarrr, может быть Вы что подскажите?

Добрый день. Использую sd карту Kingston 2Gb в spi режиме. Все было хорошо, пока не закупили карты другого производителя Silicon Power 2Gb. Суть проблемы в следующем. Данные записываются в мультиблочном режиме(ACMD23+CMD25). После посылки первого блока данных карта возвращает Data Response Token = Data accepted, а для последующих блоков Data Response Token вообще не приходит(принимается 0xff). После некоторого числа попыток ACMD23+CMD25 карта благополучно зависает и перестает отвечать вообще до пересброса питания. Просадок по питанию во время работы нет, неиспользуемые линии через 10к подтянуты к +3.3В. Частота spi = 12,5МГц. Пробовал частоту уменьшать в два раза, не помогает. Знающие люди, подскажите в чем может быть дело.

Наши логи практически совпадают, только после команды AT я еще посылаю команду ATQ0V1E0, забыл написать. Ну и сигналы RTS/CTS у меня используются, поэтому посылаю AT+IFC=2,2 . Может быть дело в прошивке модуля, всю голову уже сломал, не работает и все тут...

Добрый день! Пытаюсь скачать тестовый файл по FTP. Инициализирую модем, устанавливаю соединение, но при попытке получить файл получаю ошибку 214[Network error]. Подскажите в чем может быть дело. Лог обмена привожу ниже ниже: AT [OK] AT+IFC=2,2 [OK] AT+CREG=0 [OK] AT+CMTE? [+CMTE: 0,30] [OK] AT+CPIN? [+CPIN: READY] [OK] AT+CREG? [+CREG: 0,1] [OK] AT+CGATT=1 [OK] AT+CGATT? [+CGATT: 1] [OK] AT+CFTPSERV="ftp.yandex.ru" [OK] AT+CFTPPORT=21 [OK] AT+CFTPMODE=1 [OK] AT+CFTPTYPE=I [OK] AT+CFTPUN="anonymous" [OK] AT+CFTPPW="anonymous" [OK] AT+CGSOCKCONT=1,"IP","internet.mts.ru",,0,0 [OK] AT+CSOCKAUTH=1,1,"mts","mts" [OK] AT+NETOPEN [OK] [+NETOPEN: 0] AT+NETOPEN? [+NETOPEN: 1] [OK] AT+CFTPGET="/pub/linux/kernel/READMY" [OK] [+CFTPGET: 214]

К сожалению времени на ожидание нет. Сейчас юзается XDS100, так я вообще все нервы измотал уже с ним. А сроки поджимают. Спасибо за информацию. Для следующих проектов самое то будет.

Это видел. Указаны только поддерживаемые семейства, скоростных характеристик нет. А вообще нужна сравнительная таблица.

А можно на эти самые характеристики взглянуть? Не могу нигде найти...