STM32+SDIO+SDHC16Gb

[Vitaliki]

Читать тему сначала не пробовали?

В прилагаемой библиотеке есть следующая функция:
/* SDTransferState: Data Transfer state.
* This value can be:
* - SD_TRANSFER_OK: No data transfer is acting
* - SD_TRANSFER_BUSY: Data transfer is acting
*/
SDTransferState SD_GetStatus(void)

Пробовал её применять, однако ошибки записи никуда не делись. Может, проверяю не так.
И правильно ли проверять готовность контроллера карты по окончанию передачи данных. Он ведь не только поток данных принимает, но и что-то с ним дальше делает. А это к передачи уже отношение не имеет.

[black27512]

А что тут понимать? FatFs ChaN это библа файловой системы, к работе с SD она не имеет непосредственного отношения, только косвенное.

Дык вот то и понимать через что эта библа контачит с флешкой. То что сама FatFs тут не виновата это понятно.

[black27512]

И правильно ли проверять готовность контроллера карты по окончанию передачи данных. Он ведь не только поток данных принимает, но и что-то с ним дальше делает. А это к передачи уже отношение не имеет.

Ничего это не даст, смотрите функцию MMC_disk_write, там проверка на завершение и так производится. И пока процесс не завершится функция продолжает ждать.
Попробуйте по железу увеличить толщину шин питания и керамику+электролит прямо на выводах питания слота SD. Ну и про резисторы подтягивающие к +3.3в 47кОм не забывайте (все сигналы кроме CLK).

[realid]

И правильно ли проверять готовность контроллера карты по окончанию передачи данных. Он ведь не только поток данных принимает, но и что-то с ним дальше делает. А это к передачи уже отношение не имеет.

Если вы внимательно проследите выполнение функции SD_GetStatus, то все поймете. Все там проверяется, а SD_TRANSFER_OK и SD_TRANSFER_BUSY указывают карта готова принимать новые данные или нет, потому что если карта находится в состоянии программирования, то результат будет SD_TRANSFER_BUSY.

[Hives]

realid
не совсем так, точнее совсем не так
карта может вернуть статус SD_TRANSFER_OK и не быть готовой к записи
а вот для готовности там есть еще один бит статуса - READY_FOR_DATA (в реплике R1)
который и надо мониторить (дополнительно к TRAN состоянию)

PS за подробностями - в описание протокола SD, пункт 4.3, Write Data

[HardWareMan]

Отмечусь тоже.

В сети ходят много SD драйверов через SDIO, и судя по коду они основаны на каком-то одном общем предке. И у всех у них есть один и тот же косяк, заключающийся в адресации. Помимо него, есть другой косяк в мультиблочных командах, но они не критичны. Так вот, после исправления этого косяка согласно букварю на карты у меня взлетели SDXC, это которые больше 32ГБ. В данный момент, летает SDXC 64ГБ через DMA. До этого работали только SD и SDHC. Причем, заметно было именно в связке с FatFS. Так что делайте выводы сами.

[Easyrider83]

Здорово, конечно, но было бы еще лучше поделиться результатом. А то все только якают и мнекают, а пользы не много выходит.

[realid]

realid
не совсем так, точнее совсем не так
карта может вернуть статус SD_TRANSFER_OK и не быть готовой к записи
а вот для готовности там есть еще один бит статуса - READY_FOR_DATA (в реплике R1)
который и надо мониторить (дополнительно к TRAN состоянию)

PS за подробностями - в описание протокола SD, пункт 4.3, Write Data

Вот это поворот. Я вот считал что, если карта вернулась в Transfer State это значит она готова принимать новые команды и данные.

В сети ходят много SD драйверов через SDIO, и судя по коду они основаны на каком-то одном общем предке. И у всех у них есть один и тот же косяк, заключающийся в адресации.

Это что за косяк? Тот что, при записи/чтении одним картам(старым, v1 так называемым)нужен адрес абсолютный, а следующим в поколении(v2, HC и тп) уже номер блока(сектора)?

Помимо него, есть другой косяк в мультиблочных командах, но они не критичны.

Какой?

Так вот, после исправления этого косяка согласно букварю на карты у меня взлетели SDXC, это которые больше 32ГБ. В данный момент, летает SDXC 64ГБ через DMA. До этого работали только SD и SDHC. Причем, заметно было именно в связке с FatFS.

Что исправили и где?

[black27512]

Вот здесь относительно рабочий вариант https://github.com/nemuisan/STM32Primer2_GPS_Tracker
Только я выкидывал FatFS, мне нужна была чисто работа с блоками карты напрямую. Косяк с адресацией там исправлен (собственно косяк чисто в том, что адрес передается в uint32 и т.к. он передается не в блоках, а в байтах то для SDXC 32 бита не хватает для полной адресации, достаточно перейти на тип uint64 и всё норм будет). Ну и по инициализации там пара бит добавлено (информирование карты о том, что хост поддерживает SDXC).
Мультиблок в той либе поправлен и он там работает, но поправлен костылем в виде длинной паузы (об этом писал выше), ну и как это победить тоже описал выше.
Выложить готовое не могу, т.к. проект зашел в тупик (по причине тормознутости SD карт при записи каких-то областей и переполнению ОЗУ МК входящим потоком) и варианта "бери и пользуйся" не получилось. Буду прикручивать буфер из внешнего ОЗУ, а в таком случае мне SPI оказался ближе и бюджетнее.

[Vitaliki]

Что исправили и где?

Вот натыкался на подробные пояснения: https://gist.github.com/voidlizard/2202952