[account3847 0]

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

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

Т.е. они расчитаны на штатную работу, когда все нужные биты выставляются как надо. Однако стоит поднести к устройству с картой работающую электродрель :rolleyes:, как этот код перестаёт работать (спотыкается на этих ожиданиях и не может из них выйти). К сожалению, такое может произойти и от других внешних факторов.

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

[jorikdima 0]

использовать таймауты в таких ожиданиях или если грубо действовать то watchdog

[_3m 4]

Есть устройство с ARM7, которое общается с SD-картой по SPI.

...

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

Сочуствую. У вас случилась jopa!

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

Еще и недокументированные "особенности" порта spi под воздействием помех вылезут.

Ей богу убиться ап стену и то будет не так мучительно.

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

[aaarrr 61]

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

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

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

[_3m 4]

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

Сразу видно что вы даже не задумывались о проблеме.

Какова должна быть реакция системы на бит 19 (ERROR - A general or an unknown error occurred during the operation) в Card Status ???

Или вы подаете заведомо корректную команду а в ответ неожиданно получаете ILLEGAL_COMMAND ???

И что делать если карта показывает busy гораздо дольше паспортного времени выполнения команды ?

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

А мы еще не дошли до

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

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

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

с проблемами нужно бороться на всех уровнях

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

[aaarrr 61]

Сразу видно что вы даже не задумывались о проблеме.

Не делайте поспешных выводов.

 

Какова должна быть реакция системы на бит 19 (ERROR - A general or an unknown error occurred during the operation) в Card Status ???

Или вы подаете заведомо корректную команду а в ответ неожиданно получаете ILLEGAL_COMMAND ???

И что делать если карта показывает busy гораздо дольше паспортного времени выполнения команды ?

Во всех случаях, кроме ошибок CRC - переинициализация карты после нескольких попыток.

 

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

Переинициализация карты объект взорвет? Ну-ну.

 

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

Да, рано или поздно в ваш объект попадет молния. "Пытаться выжить до конца" есть глупость несусветная, сами же писали:

что там будет вытворять встроенный контроллер - хз

[Faradey 0]

ГУ-49А вам все правильно сказали aaarrr и jorikdima при разработке драйвера нельзя полагаться на 100% устройчивость переферии

и как следствие интсрукций вида

while(!SSPSR_bit.TNF);

не применять вовсе.

 

вот например мой кусочек драйвера MMC/SD:

/**
* @brief Читаем заданное количество секторов
* @param card  указатель на исп. карту
* @param buf    указатель на буфер-приемник
* @param sector адресс сектора с которого начинаем чтение
* @param count  количество читаемых секторов
* 
* @return int !=0 означает ошибку
*         1 - send command error
*         2 - wait data
*/
int MSC_ReadSectors( volatile MSC_CardType *card, u8 *buf, u32 sector, u32 count )
{
    ASSERT_MSC( IS_NOT_NULL( card ) );
    ASSERT_MSC( IS_NOT_NULL( card->platform ) );
    ASSERT_MSC( IS_NOT_NULL( buf ) );
    
    if( card->shared_spi )
    {
        _MSC_SPI_TakeMutex( card->platform );
        _MSC_SPI_HighSpeedInit( card->platform );
    }
    
    int r = 0;
    int j;
    
    for( int i = 0; i < count; i++ )
    {
        if( MSC_SendCommand( card,
                             cmdREAD_SINGLE_BLOCK,
                             ( sector + i ) * card->block_len ) )
        {
            r = 1;
            break;
        }
        for( j = card->config->wait_data; 
           j && ( MSC_START_SINGLE_BLOCK != _MSC_SPI_ByteWR( card->platform, 0xff ) ); j-- )
        {
            _MSC_DelayMS( card->platform, 1 );
        }
        if( !j )
        {
            card->last_err = mscERR_LONG_RDATA;
            r = 2;
            break;
        }
        u16 size = card->block_len;
        if( _MSC_SPI_ReadBuffer( card->platform, buf, size ) )
        {
            // timeout error
            card->last_err = mscERR_LONG_RDATA;
            r = 3;
            break;
        }
        // CRC
        _MSC_SPI_ByteWR( card->platform, 0xff );
        _MSC_SPI_ByteWR( card->platform, 0xff );
        _MSC_SPI_ByteWR( card->platform, 0xff );
    }
    
    _MSC_ResetCS( card->platform );
    
    if( card->shared_spi )
    {
        _MSC_SPI_GiveMutex( card->platform );
    }
    
    return r;
}

[account3847 0]

Спасибо всем, кто ответил!

 

вот например мой кусочек драйвера MMC/SD:

Можно ли увидеть кусочек _MSC_SPI_ReadBuffer()?

Интересует, прежде всего, логика генерации ошибки таймаута.

 

И как система восстанавливается после подобных ошибок?

Попадает ли эта ошибка сразу на application level или всё исправляется ещё на уровне драйверов? (Filesystem? MMC? SPI?)

В каких случаях делается полная переинициализация карты памяти?

[account3847 0]

Проблему решил грубо: при малейшей ошибке в любом из драйверов высокоуровневая операция с файлом прерывается, карта переинициализируется, файловая система перемонтируется, файлы переоткрываются и операция с файлом повторяется. Вроде работает.