Помехоустойчивая работа с SD-картой Опции

[ГУ-49А]

Есть устройство с ARM7, которое общается с SD-картой по SPI. На карте - файловая система, и файлы пишутся/читаются. Код работы с SD/MMC взят "стандартный" (IAR'овский), в котором повсюду конструкции вида

Код

while(!SSPSR_bit.TNF)
;
...
while(!SSPSR_bit.RNE)
;

Т.е. они расчитаны на штатную работу, когда все нужные биты выставляются как надо. Однако стоит поднести к устройству с картой работающую электродрель , как этот код перестаёт работать (спотыкается на этих ожиданиях и не может из них выйти). К сожалению, такое может произойти и от других внешних факторов.
Интересует программное решение данного вопроса. Т.е. хотелось бы иметь более надёжный robust код, который мог бы восстанавливаться после любой ситуации на шине. Чтобы не изобретать велосипед, поделитесь, пожалуйста, ссылкой на надёжную реализацию MMC/SD или расскажите, как её сделать?

[_3m]

Есть устройство с ARM7, которое общается с SD-картой по SPI.
...
они расчитаны на штатную работу, когда все нужные биты выставляются как надо. Однако стоит поднести к устройству с картой работающую электродрель , как этот код перестаёт работать

Сочуствую. У вас случилась jopa!
Вам придется медленно и печально перелопачивать весь код. Причем еще придется ломать голову над тем в какие состояниия попадает карта под воздействием помехи и как из этого корректно выйти. Кстати в спецификации sd о помехах, сбоях и некорректных состояниях нет ни слова, что там будет вытворять встроенный контроллер - хз
Еще и недокументированные "особенности" порта spi под воздействием помех вылезут.
Ей богу убиться ап стену и то будет не так мучительно.
Может вам подумать об использовании просто голых чипов памяти, хотя бы избавитесь от непредсказуемости?

[aaarrr]

Кстати в спецификации sd о помехах, сбоях и некорректных состояниях нет ни слова, что там будет вытворять встроенный контроллер - хз

В спецификации SD все замечательно прописано - таймауты, ошибки и т.п. Если аккуратно и внимательно ей следовать, то проблем не будет. Другое дело, что какие-то действия в случае отказа карты должен предпринимать верхний уровень - пользователю пожаловаться, переинициализировать/питание передернуть и т.д.
Ну и конечно бороться программными методами с аппаратными проблемами совершенно бесполезно.

[_3m]

В спецификации SD все замечательно прописано - таймауты, ошибки и т.п. Если аккуратно и внимательно ей следовать, то проблем не будет.

Сразу видно что вы даже не задумывались о проблеме.
Какова должна быть реакция системы на бит 19 (ERROR - A general or an unknown error occurred during the operation) в Card Status ???
Или вы подаете заведомо корректную команду а в ответ неожиданно получаете ILLEGAL_COMMAND ???
И что делать если карта показывает busy гораздо дольше паспортного времени выполнения команды ?
В общем все это хотя бы перечислить на бумаге с указанием возможных путей разруливания - уже сизифов труд.
А мы еще не дошли до

какие-то действия в случае отказа карты должен предпринимать верхний уровень - пользователю пожаловаться, переинициализировать/питание передернуть и т.д.

Встраиваеое устройство часто работает в автономном полете, жаловаться ему некому. Переинициализация как и ватчдог прервет нормальную работу системы, к чему объект управления или мониторинга может быть в данный момент не готов (проще говоря взорвется нафиг если им внезапно перестать управлять).

Ну и конечно бороться программными методами с аппаратными проблемами совершенно бесполезно.

с проблемами нужно бороться на всех уровнях
Рано или поздно найдется такая помеха которая пролезет через самые эффективные фильтры и уложит вашу систему. Как назло это случится в самый неподходящий момент. Поэтому пытаться выжить надо до конца, а не как в усб: единичный сбой->прекращение обмена