Здравствуйте
Сделал драйвер для работы с SDHC картой на STM32F407. Раз в 3 секунды непрерывно записываю данные в файл, файловая система FAT32. Работаю через SPI. Некоторые карты перестают работать(а какие-то совершенно нормально работают) через несколько часов непрерывной записи. Посмотрел осциллографом, карта после операции записи в сектор не выходит из состояния busy. При этом возвращается статус о корректном завершении операции записи.В чем может быть проблема?

Не знаю. У меня такая же проблема, но на SDIO. Отправить карту в нокаут просто: записываем сектор, затем читаем какой-то сектор.
Если перед чтением поставить задержку, то все ок. Если снизить частоту интерфейса, то все ок.
Что только не делал со статусом карты и битами SDIO - результат нулевой.
Писать на карту можно сколь-угодно долго - никаких проблем. Но последователь чтение-запись-чтение без пауз - получаем из любой карты busy-труп.
В Спецификации SD и в Интернете - пустота по этому вопросу.

Т.е. попробовать снизить частоту записи? Да,действительно, в спецификации ничего не сказано. Но есть еще один эффект, когда перебиваешь питание прибора, и соответственно, SDHC карты, то карта продолжает сбоить на этом же месте.Т.е. дальше запись не идет. Первое же чтение-запись и намертво залипает в busy

Нет - запись можно вести потоком без каких-либо пауз с максимально возможным темпом.
Как только в статусе появляется ready - сразу же начинаю новую запись, и нет проблем.
Но при использовании FAT нужно получать очередной свободный кластер, для этого придется считать с карты.
Так вот такое считывание после предварительной записи отправляет карты в вечный busy.

Скорее всего, это момент считывания таблицы FAT для поиска свободного кластера.

А как это можно победить?

Как победить - не знаю.
Я сделал костыль: в функции "записать сектор" смотрю, если перед этим была операция чтения, то выжидаю некую паузу.
Выше слегка наврал: проблема происходит после запись-чтение-запись.
Если сделать запись-чтение-пауза-запись, то все ок.

Просто для статистики. Используете HAL или StdLib ???

Была такая проблема с определенными секторами. По моему с секурити областями связано. Так и не решил. Использовал другую карту где отсутствует такая вещь. Было еще пару проблем с делай тимингами CS линии, когда привинчивал FAT через SPI.

В копилку статистики: я не использую.

Извиняюсь за оскорбление Вашего трудового стажа .

На старой работе, где руководство запрещало "собственные велосипеды", в одном из проектов я принципиально решил использовать StdLib и другие
готовые решения (FreeRTOS, uIP). Докладываю: это был первый и последний раз. По времени разработки, изучения, решения проблем - сделать
свой велосипед было бы гораздо легче и лучше. Мне повезло, что у меня уже есть богатая библиотека решений, но для новичков со стандартными
средствами запуск будет быстрее, чем писать все самому. При этом помним большими буквами, что применение библиотек не освобождает
от необходимости чтения DS, RM, AN и т.п. Иногда приходится изучать StdLib|HAL, чтобы понять как производитель рекомендует работать.

https://www.lijingquan.net/wp-content/uploa...icationV6.0.pdf
Страница 35.
Переходы межу операциями чтения и записи - должны подтверждаться сменой статуса режима карты. Через определённое время бездействия (зависит от карты) - алгоритм сам переходит в состояние Stand-by State, даже без проверки статуса. Но это время не нормированное, почти лотерея.
И да, писать драйвер для SD - это наверное второе по увлекательности занятие.

Карта, с которой работаешь должна быть в режиме "tran". Из этого режима ее можно читать и писать.
Про произвольный переход по таймауту в режим "stby" ничего не знаю - Card State Transition Table говорит,
что из "tran" в "stby" можно попасть только через CMD7.

Это так, но при длительной записи - встроенный в карту микропроцессор оптимизирует запись, проще говоря - не снимает режим записи. Это часть оптимизации на скорость. Когда чтение чередуется с записью - команды выполняются безусловно.
Этот эффект можно увидеть на графиках скорости записи разных карт одного класса, всегда есть такие что чуть-чуть вырываются в перёд.

Правильно я понимаю, и перед записью и перед чтением есть проверка на состояние "tran"?
и все равно - нокаут, если не вставить задержку?

Ага. Каждая процедура чтения и записи сектора начинается с CMD13_SEND_STATUS.

А какая необходима минимальная пауза?

Точных данных нет. У меня сделано костыльно: в функции записи смотрю - если перед этим было чтение, то тупо делаю 500 раз SDIO_Delay().
Но уму в такой ситуации нужно запускать задержку в фоне, возвращать управление из функции, при сработке задержки делать запись и в конце рапортовать через callback-функцию.
Но потом забросил отладку записи и не стал ничего переделывать.

Понятно, спасибо.

А как у вас запись чтение происходит ? одним блоком или мультиблочно? У меня похожая проблема(на SDIO), посекторно пишет считывает, без проблем(пробовал всякие комбинации R-W-R), как только начал использовать FAT сразу повисла, вот задумался если, переделать на мультипольный вариант даже для 1 сектора, и гнать в конце команду CMD12, что нибудь измениться или нет.

Использую CMD18_READ_MULTIPLE_BLOCK + CMD12_STOP_TRANSMISSION для чтения,
и ACMD23_SET_WR_BLK_ERASE_COUNT + CMD25_WRITE_MULTIPLE_BLOCK + CMD12_STOP_TRANSMISSION для записи.
Перед и после операций - CMD13_SEND_STATUS.