Arxi

Ну FatFs тоже поддерживает файловую систему exFat или главный момент вашего комментария кроется в словах "со специальным механизмом защиты от сбоев"?

Симптомов пока нет, так как код ошибки еще не выловил.

Ну пока пытаюсь ее поймать. Хаотично возникает: может работать несколько часов, а может минут 40. Просто как только запускаю в отладчике, чтобы прочитать код ошибки, то она как назло работает без ошибок, а как только без отладчика - так бывает возникает. Допустим f_write вовзращает FR_DISK_ERR или FR_INVALID_OBJECT, допустим какой то сбой или помеха возникла при записи. Какие дальнейшие действия? Или у всех при работе с SD все работает безупречно в идеальных условиях и никто не делает обработку ошибок?

Такой вопрос к знатокам: если в процессе работы с картой возникает какая либо ошибка (на уровне драйвера SDIO или на уровне FATfs) для дальнейшей работы достоточно сделать ремаунт карты и заново открыть файл или необходимо снимать питание с карты памяти?

Интересно, а класс карты как то сказывается на работе с ней? Меняются ли тайминги и необходимые задержки при этом? Карты ниже классом может быть более устойчивы ко всяким наводкам и внешним воздействиям?

Учту. Спасибо за совет.

Про электролиты не согласен. Все таки потребление большое, и я думаю электролит точно не помешает.

Стоит электролит 100мкФ непосредственно на выводах разъема карты...

По питанию емкость стоит, резисторы подтяжки тоже. Длина проводов сантиметров 5...Может быть дело в питании у меня, с увеличением частоты тактирования растет и потребление. Просто питается МК и карта у меня от линейного стабилизатора 3,3В с максимальным током 100мА...Может быть в этом дело... Хотя по спецификации SanDisk ток потребления в режиме Read/Write заявлен 100mA.

Ну вот пока что уменьшением частоты тактирования SDIO до 1МГц добился того, что работают все карты которые у меня сейчас есть. И это на макете с проводами. Поэтому дальше посмотрим что будет с нормальной печатной платой.

После f_mount получаю FR_OK, заполняются структуры с данными о карте, в том числе считывается CSD карты - 400e00325b59000076b27f80a404012. С помощью сайта https://goughlui.com/static/csdecode2.htm CSD можно легко расшифровать: правильно определяется тип, объем, размер блока карты. То есть драйвер вроде как работает, раз все считывается? А f_open все равно выдает ошибку FR_NO_FILESYSTEM. Просто уже голова идет кругом, вроде как низкий уровень работает (я имею в виду сам алгоритм общения с картой), раз работают карты на 2 и 8Гб, да и с 16Гб картой f_mount успешно проходит...Что не так с f_open то может быть...? UPDATE. Хм....в общем частота тактирования SDIO стояла 4.5МГц, уменьшил ее до 1 МГц и 16Гб карточка успешно завелась и работает!...Очень странно. У меня просто это все сделано в виде макета, длина проводов некоторая тоже присутствует, поэтому о частотах 24МГц я даже и не думал. А тут вот так из-за частоты какие то проблемы...Тему можно закрывать...Буду делать уже полноценный прибор с минимальной длинной дорожек и смотреть дальше..Всем спасибо!

Я думаю тут еще влияет какой чип вы использовали, ведь библиотеки куба могут отличаться от чипа к чипу...

Как раз для этого на DMA то и перешел.

SDIO - 4b. 1b режим как то не пробовал еще. Да. Спасибо за вопрос, сам как то не думал в этом направлении. Откатил версию до переделки DMA (благо Git использую). И получается странная ситуация: без DMA работают все карты (SDSC 2Гб и SDHC 8 и 16Гб), но из-за того что на время записи приходится отключать прерывания (иначе вылазила ошибка при записи), в лог файле получается пауза с пропусками информации. Решил эту проблему подключением DMA. Но с DMA работают только карты 2 и 8 Гб, а 16Гб отказывается работать. Есть над чем подумать...

Без нареканий - это значит что f_mount, f_open, f_write, f_sync работают без проблем. Самый большой файл, который записывался - 300Мб (писал уже выше). Открывается нормально. Ньюансы есть, как и всегда. Например то, что : In a multibyte transfer operation, CMD53 will transfer only a number of bytes that is equal to a power of 2 (1, 2, 4, 8...512) between 1 and 512.