[powerchip 0]

Всех приветствую.

Такое непонятное явление происходит. Имеется девайс, который пишет на sd карту звуковые файлы по 10 мин в течении нескольких часов, затем отправляет их пользователям и удаляет. Файл записывается так: открываем, пишем блоками по 4096 байт, закрываем. Так вот через примерно неделю работы скорость записи такого блока (4096 байт, хотя от размера время блока не сильно зависит) резко уменьшается. Нормально запись проходит примерно за 10 мс, а при медленной записи 60 мс. Самое интересно что после полного форматирования в винде или просто проверки на ошибки и скорость работы утилитой типа check flash скорость записи восстанавливается. При этом проверки различными утилитами на ПК не дают никаких ошибок и скорость записи меряют нормальную

Используется STM32L476 + SDIO (4 bit с DMA) + FatFS + FreeRTOS. Все стандартное ST-шное из CubeMX.

SD карта Sandisc 10 класс

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

Может сталкивался кто с таким поведением sd карты во встраиваемых системах?

[haker_fox 60]

Встречался с подобным, когда записывалось около 20000 файлов в одну директорию. Разнесение файлов по каталогам помогло.

[powerchip 0]

Интересный опыт, но у меня не было никогда такого количества файлов, макс 200.

Кроме того какая файловая система у вас была? Если FAT16 то там макс 512 элементов в корневом каталоге. У меня FAT32 там 65536 может быть.

Замечено что карта начинает писать медленно не зависимо от того какое количество файлов на ней. Интересно что первые несколько блоков файла (штук 10 примерно) пишутся с нормальной скоростью а остальные медленно, наблюдал это осциллографом: замедляется именно вот это место :

 

if(BSP_SD_WriteBlocks_DMA((uint32_t*)buff, (uint32_t)(sector), count) == MSD_OK)
  {           
      /* Get the message from the queue */
      
    event = osMessageGet(SDQueueID, SD_TIMEOUT); 

    TEST_GPIO_Port->BSRR |=TEST_Pin;    
      
    if (event.status == osEventMessage)
    {
      if (event.value.v == WRITE_CPLT_MSG)
      {        
          timer = osKernelSysTick() + SD_TIMEOUT;
        /* block until SDIO IP is ready or a timeout occur */                 
          
        while(timer > osKernelSysTick())
        {                                
          
          if (BSP_SD_GetCardState() == SD_TRANSFER_OK)
          {
            res = RES_OK;
            break;
          }                 
        }                  
      }      
    }
    TEST_GPIO_Port->BRR |=TEST_Pin;
     
  }

т.е. отправляем команду болчной записи, сами данные по DMA и ждем ответа что данные приняты картой (event = osMessageGet(SDQueueID, SD_TIMEOUT); ) и затем что запись завершена:

while(timer > osKernelSysTick())
        {                                
          
          if (BSP_SD_GetCardState() == SD_TRANSFER_OK)
          {
            res = RES_OK;
            break;
          }                 
        }        

Вобщемя четко видно что именно карта долго отвечать начинает.

 

27 minutes ago, haker_fox said:

Встречался с подобным, когда записывалось около 20000 файлов в одну директорию. Разнесение файлов по каталогам помогло.

А чем можно объяснить такое явление? 

Изменено 16 мая, 2019 пользователем powerchip

[haker_fox 60]

5 minutes ago, powerchip said:

Если FAT16 то там макс 512 элементов в корневом каталоге

FatFS, FAT32.

6 minutes ago, powerchip said:

А чем можно объяснить такое явление? 

Честно говоря, не разбирался. Предположил, что по какой-0то причине увеличивается время поиска свободного места в директории.

[powerchip 0]

3 minutes ago, haker_fox said:

FatFS, FAT32.

Честно говоря, не разбирался. Предположил, что по какой-0то причине увеличивается время поиска свободного места в директории.

А вы не замеряли точное количество файлов в корневом каталоге, после которого происходит подобное явление? И если в вашем случае просто стереть все файлы и заново начать писать, то они нормально писались до достижения определенного количества файлов, или только полное форматирование помогало (в моем случае быстрое форматирование не помогает, но что интересно после проверки программкой check flash (проверяет ошибки диска, файловой системы и скорости чтения записи) скорость восстанавливается (ошибок никаких не находит и не исправляет), уж не знаю что она там делает, но она даже не форматирует карту, так как файлы которые на ней были остаются нетронутыми).

[Forger 17]

3 hours ago, powerchip said:

Может сталкивался кто с таким поведением sd карты во встраиваемых системах?

Растет фрагментация файловой таблицы. Логично, что после форматирования это явление полностью устраняется.

Как одно из решений - создавать файлы строго пропорционально размеру кластера.

Другой вариант - периодическое форматирование прямо в устройстве.

[x893 33]

Причем тут файлы если у него карта операцию записи делает медленнее ?

В примере про файловую систему ни слова нет.

А почему нельзя навставлять вызовов для SystemView (ну или хотя бы сообщений) и сделать анализ работы за неделю/месяц ?

[Forger 17]

7 minutes ago, x893 said:

Причем тут файлы если у него карта операцию записи делает медленнее ?

Тогда как объяснить это:

Quote

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

?

[aaarrr 61]

14 minutes ago, Forger said:

Тогда как объяснить это

 

3 hours ago, powerchip said:

в моем случае быстрое форматирование не помогает, но что интересно после проверки программкой check flash (проверяет ошибки диска, файловой системы и скорости чтения записи

То есть восстанавливается после массовой записи. Скорее всего, и в устройстве скорость записи восстановится через некоторое время.

 

Карта - изделие весьма сложное, производителей масса. Исследовать поведение конкретного экземпляра смысла не имеет.

[x893 33]

2 hours ago, Forger said:

Тогда как объяснить это:

?

Тут только могу предположить, что в самой карте делается переназначение плохих блоков и, например, когда пишем в сектор, который физически дефектный, происходит поиск свободного.

Проверить просто. взять и писать подряд в блоки и посмотреть время зпаси.

Если предположение верное, то на каких то блоках будет время увеличенное.

[Forger 17]

1 hour ago, x893 said:

Тут только могу предположить, что в самой карте делается переназначение плохих блоков и, например, когда пишем в сектор, который физически дефектный, происходит поиск свободного.

Если сектор помечен как битый, то хорошим он не уже станет, его более не будет в цепочке доступных секторов. Особенно после банального форматирования (очистка таблицы FAT).

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

 

 

[aaarrr 61]

1 hour ago, x893 said:

в самой карте делается переназначение плохих блоков

Только не плохих, а вообще - перенос данных из частично заполненных блоков, выравнивание износа и вся прочая кухня.

[powerchip 0]

15 hours ago, aaarrr said:

 

То есть восстанавливается после массовой записи. Скорее всего, и в устройстве скорость записи восстановится через некоторое время.

 

Карта - изделие весьма сложное, производителей масса. Исследовать поведение конкретного экземпляра смысла не имеет.

Приятно видеть что данный вопрос стал интересен многим людям.

 

Вчера также пришла в голову такая же мысль про массовую запись, т.к. программа тестирования карта кроме в первую очередь делает именно это: массовая запись - чтение (причем целыми кластерами, которые в моем случае 32 Кбайт, памяти то в компе много, а я больше 4 Кб на буфер записи в девайсе выделить не могу), таким образом выясняет скорость работы и отсутствие ошибок. Я просто взял одинаковые файлы по 10 Мб и записал на компе в проводнике 300 Мб на карте. Потом стер, вставил в девайс и там запись началась нормальная. Хотя если делать тоже с самое в девайсе скорость не восстанавливается.

 

Очевидны следующие омменты:

 

1. как минимум FatFS + драйвер SD из CubeMX и винда по разному работают с картой.

 

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

 

3. "Если предположение верное, то на каких то блоках будет время увеличенное." - вряд ли есть смысл в данном тесте, т.к. время записей всех блоков по 4096 байт (либо меньшее кратное 512 (сектору)) подряд одинаково увеличенное (не все же они плохие), кроме данное явление возникает на всех параллельно работающих устройствах через одинаковый промежуток времени .

 

4. "Как одно из решений - создавать файлы строго пропорционально размеру кластера." - на практике это сделать очень не просто, тот же WAV файл имеет заголовок всего 44 байта, никуда его не денешь, а остальные данные строго кратны 512 байтам, т.к. зашифрованы AES блоками этого размера, т.е. полюбому окончание файла будет не кратно кластеру и даже сектору (последний записанный сектор будет содержать только 44 байта полезной информации). Кроме того не вижу проблемы с кратность кластеру или даже сектору: 1. секторы начиная с начала файла пишем кратно сектору 512, в последний сектор пишем 44 и делаем f_close, в FAT все кластеры включая последний помечаются FatFS как надо - все в ажуре. 2. следующий файл пишется с нового кластера. Т.е. по теории все должно быть нормально, никакой фрагментации прочей. Кроме того, учитывая что кластер 32 Кбайт, а переходов границы кластера во время записи блоков (напоминаю это 4 К, т.е. 8 секторов) вообще никак не видно (не отличается время записи блока секторов что в середине кластера что на границе, и плюс к тому невозможна ситуация когда блок записываемых секторов частично в одном кластере а частично попадает в следующий, т.к. блок 4 К кратен 32 К), и очевидно какая либо  не выровненность по кластрерам сама по себе не возникает и никак не влияет. Невыровненность по кластерам можно допустить только если какой то сбой в файловой системе и происходит все не так как я описал.

 

5. Файлы пишутся подряд,и удаляются тоже подряд - никаких манипуляций с содержимом в середине (переименованием, переносом, изменением и т.д.), например "стерли пятый из 10 имеющихся" нет - не должно быть фрагментации.

 

6. "перенос данных из частично заполненных блоков, выравнивание износа и вся прочая кухня" - это конечно весело, но зачем тогда контроллер в SD (именно он заботиться о равномерности износа и битых секторах), библиотека FatFS и CubeMX - не для того ли чтоб жизнь упростить, время сэкономить, и надежность системы повысить. И главное времени на такие вещи совсем нет, даже драйвер свой для работы с картой не могу написать, пользуюсь тем что CubeMX со своим HAL предложил, т.к. работа с картой это только маленький этап всего проекта, предполагалось что раз и все заработало, как в примерах, а тут такое недоразумение. Но надо заметить у ST не все так плохо, например их библиотека шифрования и библиотека обработки звука сразу заработали без вопросов (правда друг с другом ресурсы сопроцессора поделить не смогли, пришлось в ручную их делить).

 

Работал раньше с другими типами памяти и разными микроконтроллерами, но никогда никакими библиотеками не пользовался (кроме графической для LCD от Texas, но там тоже дрова на экран самому писать надо ), в том числе использовал Flash (NOR) и другие питы памяти, сам все дрова писал и с памятью напрямую работал, проблем никогда никаких не было, по крайне мене всегда можно было докопаться до истины и понять что и как работает, а тут куча всяких прокладок-черных ящиков появилась таких, FatFs и HAL из CubeMX (проект изначально не я начинал, сам я кубом и HAL не пользуюсь) и все куча проблем на ровном месте. Начинаешь какую функцию ковырять, типа запись файла и просто поражаешься как можно было элементарные операции так запутать, усложнить и код раздуть с помощью HAL, сложно там ошибки искать, а они есть и совсем не очевидные.

Вообще не понятно, у людей вроде все работает в таких системах и нет упоминаний о том что кто то вообще с таким поведением системы сталкивался. Все предположения что озвучены участниками обсуждения интересны, но к сожалению пока нет 1.точного диагноза,  что же с картой, и 2. причины возникновения. Очевидно лишь что вина лежит либо на FatFS либо на драйвере SD из CubeMX, есть в них какой то косяк, который карту ставит в неудобное положение при определенных условиях. Ну а карта сама ни в чем не виновата.

 

Если есть у кого какие нибудь еще мысли пишите, если надо какие то дополнительные сведения о параметрах системы и процессе работы с картой спрашивайте я напишу.

 

Кстати на форуме ST тоже эту проблему описал, и тишина.

 

Изменено 17 мая, 2019 пользователем powerchip

[aaarrr 61]

58 minutes ago, powerchip said:

1.точного диагноза,  что же с картой,

Да все в порядке с картой, просто не любят современные носители работать с малыми блоками. Добавьте буфер записи на 32-64-128кБайт (как прослойку между FatFS и драйвером SD) - и все станет прекрасно.

[powerchip 0]

12 minutes ago, aaarrr said:

Да все в порядке с картой, просто не любят современные носители работать с малыми блоками. Добавьте буфер записи на 32-64-128кБайт (как прослойку между FatFS и драйвером SD) - и все станет прекрасно.

Полностью согласен с "не любят", но как я уже писал нет ресурсов для добавления до 32 кбайт, это в моем случае значит 64 к, но есть только память мк.

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

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

Вообще карта конечно очень интересно себя ведет: например сам процесс записи одного блока мало зависит от размера, что 512 байт что 16 кбайт, если разом писать то время не в разы отличается, а только на 50%. Если делать раздельные записи сразу друг за другом или через промежуток менее 4 мс то  каждая запись проходит быстрее в 2 раза чем если бы писать с временным интервалов более чем 4 мс (но это так эксперименты, в реальности писать могу только когда данные готовы, а это процесс строго по времени и он не попадает на хороший случай). Периодические задержки в записи по 100-500 мс это уж обычное дело для карт, я даже не смотрю на них, они не такие частые и являются естественным поведением для SD карты, с этим приходится мирится. 

Я сам понимаю что тема это совсем непростая и непонятная, тут бы совета гуру именно по FAT и sd картам услышать, сам то я вроде достаточно хорошо разобрался как все устроено и работает, но диагноз поставить опыта и фантазии все же не хватает. Думаю обойти эту проблему получится ткнув пальцем в небо, то это все же не самый лучший результат будет. Тайна останется.